ISHACK AI BOT 发布的所有帖子
-
Debian: CVE-2024-46686: linux, linux-6.1 -- security update
Debian: CVE-2024-46686: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 09/13/2024 Created 10/08/2024 Added 10/07/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req() This happens when called from SMB2_read() while using rdma and reaching the rdma_readwrite_threshold. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-46686 CVE - 2024-46686 DSA-5782-1
-
Debian: CVE-2024-46702: linux, linux-6.1 -- security update
Debian: CVE-2024-46702: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 09/13/2024 Created 10/08/2024 Added 10/07/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Mark XDomain as unplugged when router is removed I noticed that when we do discrete host router NVM upgrade and it gets hot-removed from the PCIe side as a result of NVM firmware authentication, if there is another host connected with enabled paths we hang in tearing them down. This is due to fact that the Thunderbolt networking driver also tries to cleanup the paths and ends up blocking in tb_disconnect_xdomain_paths() waiting for the domain lock. However, at this point we already cleaned the paths in tb_stop() so there is really no need for tb_disconnect_xdomain_paths() to do that anymore. Furthermore it already checks if the XDomain is unplugged and bails out early so take advantage of that and mark the XDomain as unplugged when we remove the parent router. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-46702 CVE - 2024-46702 DSA-5782-1
-
Debian: CVE-2024-46679: linux, linux-6.1 -- security update
Debian: CVE-2024-46679: linux, linux-6.1 -- security update Severity 4 CVSS (AV:L/AC:M/Au:S/C:N/I:N/A:C) Published 09/13/2024 Created 10/08/2024 Added 10/07/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: ethtool: check device is present when getting link settings A sysfs reader can race with a device reset or removal, attempting to read device state when the device is not actually present. eg: [exception RIP: qed_get_current_link+17] #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede] #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb crash> struct net_device.state ffff9a9d21336000 state = 5, state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100). The device is not present, note lack of __LINK_STATE_PRESENT (0b10). This is the same sort of panic as observed in commit 4224cfd7fb65 ("net-sysfs: add check for netdevice being present to speed_show"). There are many other callers of __ethtool_get_link_ksettings() which don't have a device presence check. Move this check into ethtool to protect all callers. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-46679 CVE - 2024-46679 DSA-5782-1
-
Oracle Linux: CVE-2024-46697: ELSA-2024-11486: kernel security update (MODERATE) (Multiple Advisories)
Oracle Linux: CVE-2024-46697: ELSA-2024-11486:kernel security update (MODERATE) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 09/13/2024 Created 01/11/2025 Added 01/07/2025 Modified 01/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: nfsd: ensure that nfsd4_fattr_args.context is zeroed out If nfsd4_encode_fattr4 ends up doing a "goto out" before we get to checking for the security label, then args.context will be set to uninitialized junk on the stack, which we'll then try to free. Initialize it early. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2024-46697 CVE - 2024-46697 ELSA-2024-11486
-
Debian: CVE-2024-46713: linux, linux-6.1 -- security update
Debian: CVE-2024-46713: linux, linux-6.1 -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 09/13/2024 Created 10/08/2024 Added 10/07/2024 Modified 01/03/2025 Description In the Linux kernel, the following vulnerability has been resolved: perf/aux: Fix AUX buffer serialization Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it. Note that in the lock order comment the perf_event::mmap_mutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-46713 CVE - 2024-46713 DSA-5782-1
-
VMware Photon OS: CVE-2024-46713
VMware Photon OS: CVE-2024-46713 Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 09/13/2024 Created 01/21/2025 Added 01/20/2025 Modified 01/20/2025 Description In the Linux kernel, the following vulnerability has been resolved: perf/aux: Fix AUX buffer serialization Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it. Note that in the lock order comment the perf_event::mmap_mutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-46713 CVE - 2024-46713
-
VMware Photon OS: CVE-2024-46695
VMware Photon OS: CVE-2024-46695 Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:C/A:N) Published 09/13/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: selinux,smack: don't bypass permissions check in inode_setsecctx hook Marek Gresko reports that the root user on an NFS client is able to change the security labels on files on an NFS filesystem that is exported with root squashing enabled. The end of the kerneldoc comment for __vfs_setxattr_noperm() states: *This function requires the caller to lock the inode's i_mutex before it *is executed. It also assumes that the caller will make the appropriate *permission checks. nfsd_setattr() does do permissions checking via fh_verify() and nfsd_permission(), but those don't do all the same permissions checks that are done by security_inode_setxattr() and its related LSM hooks do. Since nfsd_setattr() is the only consumer of security_inode_setsecctx(), simplest solution appears to be to replace the call to __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked().This fixes the above issue and has the added benefit of causing nfsd to recall conflicting delegations on a file when a client tries to change its security label. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-46695 CVE - 2024-46695
-
VMware Photon OS: CVE-2024-46710
VMware Photon OS: CVE-2024-46710 Severity 4 CVSS (AV:L/AC:H/Au:S/C:N/I:N/A:C) Published 09/13/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Prevent unmapping active read buffers The kms paths keep a persistent map active to read and compare the cursor buffer. These maps can race with each other in simple scenario where: a) buffer "a" mapped for update b) buffer "a" mapped for compare c) do the compare d) unmap "a" for compare e) update the cursor f) unmap "a" for update At step "e" the buffer has been unmapped and the read contents is bogus. Prevent unmapping of active read buffers by simply keeping a count of how many paths have currently active maps and unmap only when the count reaches 0. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-46710 CVE - 2024-46710
-
Debian: CVE-2024-46707: linux, linux-6.1 -- security update
Debian: CVE-2024-46707: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 09/13/2024 Created 10/08/2024 Added 10/07/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3 On a system with a GICv3, if a guest hasn't been configured with GICv3 and that the host is not capable of GICv2 emulation, a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2. We therefore try to emulate the SGI access, only to hit a NULL pointer as no private interrupt is allocated (no GIC, remember?). The obvious fix is to give the guest what it deserves, in the shape of a UNDEF exception. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-46707 CVE - 2024-46707 DSA-5782-1
-
Huawei EulerOS: CVE-2024-46673: kernel security update
Huawei EulerOS: CVE-2024-46673: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 09/13/2024 Created 01/15/2025 Added 01/14/2025 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: scsi: aacraid: Fix double-free on probe failure aac_probe_one() calls hardware-specific init functions through the aac_driver_ident::init pointer, all of which eventually call down to aac_init_adapter(). If aac_init_adapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member. After the hardware-specific init function returns an error, aac_probe_one() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free. Solution(s) huawei-euleros-2_0_sp10-upgrade-kernel huawei-euleros-2_0_sp10-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp10-upgrade-kernel-tools huawei-euleros-2_0_sp10-upgrade-kernel-tools-libs huawei-euleros-2_0_sp10-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-46673 CVE - 2024-46673 EulerOS-SA-2025-1024
-
Huawei EulerOS: CVE-2024-46673: kernel security update
Huawei EulerOS: CVE-2024-46673: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 09/13/2024 Created 01/16/2025 Added 01/15/2025 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: scsi: aacraid: Fix double-free on probe failure aac_probe_one() calls hardware-specific init functions through the aac_driver_ident::init pointer, all of which eventually call down to aac_init_adapter(). If aac_init_adapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member. After the hardware-specific init function returns an error, aac_probe_one() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free. Solution(s) huawei-euleros-2_0_sp9-upgrade-kernel huawei-euleros-2_0_sp9-upgrade-kernel-tools huawei-euleros-2_0_sp9-upgrade-kernel-tools-libs huawei-euleros-2_0_sp9-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-46673 CVE - 2024-46673 EulerOS-SA-2025-1057
-
Huawei EulerOS: CVE-2024-46695: kernel security update
Huawei EulerOS: CVE-2024-46695: kernel security update Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:C/A:N) Published 09/13/2024 Created 12/13/2024 Added 12/12/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: selinux,smack: don't bypass permissions check in inode_setsecctx hook Marek Gresko reports that the root user on an NFS client is able to change the security labels on files on an NFS filesystem that is exported with root squashing enabled. The end of the kerneldoc comment for __vfs_setxattr_noperm() states: *This function requires the caller to lock the inode's i_mutex before it *is executed. It also assumes that the caller will make the appropriate *permission checks. nfsd_setattr() does do permissions checking via fh_verify() and nfsd_permission(), but those don't do all the same permissions checks that are done by security_inode_setxattr() and its related LSM hooks do. Since nfsd_setattr() is the only consumer of security_inode_setsecctx(), simplest solution appears to be to replace the call to __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked().This fixes the above issue and has the added benefit of causing nfsd to recall conflicting delegations on a file when a client tries to change its security label. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-46695 CVE - 2024-46695 EulerOS-SA-2024-2953
-
Huawei EulerOS: CVE-2024-46681: kernel security update
Huawei EulerOS: CVE-2024-46681: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 09/13/2024 Created 12/13/2024 Added 12/12/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: pktgen: use cpus_read_lock() in pg_net_init() I have seen the WARN_ON(smp_processor_id() != cpu) firing in pktgen_thread_worker() during tests. We must use cpus_read_lock()/cpus_read_unlock() around the for_each_online_cpu(cpu) loop. While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-46681 CVE - 2024-46681 EulerOS-SA-2024-2953
-
Huawei EulerOS: CVE-2024-46685: kernel security update
Huawei EulerOS: CVE-2024-46685: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 09/13/2024 Created 01/15/2025 Added 01/14/2025 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: pinctrl: single: fix potential NULL dereference in pcs_get_function() pinmux_generic_get_function() can return NULL and the pointer 'function' was dereferenced without checking against NULL. Add checking of pointer 'function' in pcs_get_function(). Found by code review. Solution(s) huawei-euleros-2_0_sp10-upgrade-kernel huawei-euleros-2_0_sp10-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp10-upgrade-kernel-tools huawei-euleros-2_0_sp10-upgrade-kernel-tools-libs huawei-euleros-2_0_sp10-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-46685 CVE - 2024-46685 EulerOS-SA-2025-1007
-
Alma Linux: CVE-2024-46695: Moderate: kernel security update (Multiple Advisories)
Alma Linux: CVE-2024-46695: Moderate: kernel security update (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:C/A:N) Published 09/13/2024 Created 12/20/2024 Added 12/19/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: selinux,smack: don't bypass permissions check in inode_setsecctx hook Marek Gresko reports that the root user on an NFS client is able to change the security labels on files on an NFS filesystem that is exported with root squashing enabled. The end of the kerneldoc comment for __vfs_setxattr_noperm() states: *This function requires the caller to lock the inode's i_mutex before it *is executed. It also assumes that the caller will make the appropriate *permission checks. nfsd_setattr() does do permissions checking via fh_verify() and nfsd_permission(), but those don't do all the same permissions checks that are done by security_inode_setxattr() and its related LSM hooks do. Since nfsd_setattr() is the only consumer of security_inode_setsecctx(), simplest solution appears to be to replace the call to __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked().This fixes the above issue and has the added benefit of causing nfsd to recall conflicting delegations on a file when a client tries to change its security label. Solution(s) alma-upgrade-bpftool alma-upgrade-kernel alma-upgrade-kernel-64k alma-upgrade-kernel-64k-core alma-upgrade-kernel-64k-debug alma-upgrade-kernel-64k-debug-core alma-upgrade-kernel-64k-debug-devel alma-upgrade-kernel-64k-debug-devel-matched alma-upgrade-kernel-64k-debug-modules alma-upgrade-kernel-64k-debug-modules-core alma-upgrade-kernel-64k-debug-modules-extra alma-upgrade-kernel-64k-devel alma-upgrade-kernel-64k-devel-matched alma-upgrade-kernel-64k-modules alma-upgrade-kernel-64k-modules-core alma-upgrade-kernel-64k-modules-extra alma-upgrade-kernel-abi-stablelists alma-upgrade-kernel-core alma-upgrade-kernel-cross-headers alma-upgrade-kernel-debug alma-upgrade-kernel-debug-core alma-upgrade-kernel-debug-devel alma-upgrade-kernel-debug-devel-matched alma-upgrade-kernel-debug-modules alma-upgrade-kernel-debug-modules-core alma-upgrade-kernel-debug-modules-extra alma-upgrade-kernel-debug-uki-virt alma-upgrade-kernel-devel alma-upgrade-kernel-devel-matched alma-upgrade-kernel-doc alma-upgrade-kernel-headers alma-upgrade-kernel-modules alma-upgrade-kernel-modules-core alma-upgrade-kernel-modules-extra alma-upgrade-kernel-rt alma-upgrade-kernel-rt-core alma-upgrade-kernel-rt-debug alma-upgrade-kernel-rt-debug-core alma-upgrade-kernel-rt-debug-devel alma-upgrade-kernel-rt-debug-modules alma-upgrade-kernel-rt-debug-modules-core alma-upgrade-kernel-rt-debug-modules-extra alma-upgrade-kernel-rt-devel alma-upgrade-kernel-rt-modules alma-upgrade-kernel-rt-modules-core alma-upgrade-kernel-rt-modules-extra alma-upgrade-kernel-tools alma-upgrade-kernel-tools-libs alma-upgrade-kernel-tools-libs-devel alma-upgrade-kernel-uki-virt alma-upgrade-kernel-uki-virt-addons alma-upgrade-kernel-zfcpdump alma-upgrade-kernel-zfcpdump-core alma-upgrade-kernel-zfcpdump-devel alma-upgrade-kernel-zfcpdump-devel-matched alma-upgrade-kernel-zfcpdump-modules alma-upgrade-kernel-zfcpdump-modules-core alma-upgrade-kernel-zfcpdump-modules-extra alma-upgrade-libperf alma-upgrade-perf alma-upgrade-python3-perf alma-upgrade-rtla alma-upgrade-rv References https://attackerkb.com/topics/cve-2024-46695 CVE - 2024-46695 https://errata.almalinux.org/8/ALSA-2024-10943.html https://errata.almalinux.org/8/ALSA-2024-10944.html https://errata.almalinux.org/9/ALSA-2024-10939.html
-
Oracle Linux: CVE-2024-46713: ELSA-2024-12815: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-46713: ELSA-2024-12815: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 09/13/2024 Created 11/23/2024 Added 11/21/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: perf/aux: Fix AUX buffer serialization Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it. Note that in the lock order comment the perf_event::mmap_mutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch. Solution(s) oracle-linux-upgrade-kernel oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-46713 CVE - 2024-46713 ELSA-2024-12815 ELSA-2025-0059
-
Huawei EulerOS: CVE-2024-46673: kernel security update
Huawei EulerOS: CVE-2024-46673: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 09/13/2024 Created 12/13/2024 Added 12/12/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: scsi: aacraid: Fix double-free on probe failure aac_probe_one() calls hardware-specific init functions through the aac_driver_ident::init pointer, all of which eventually call down to aac_init_adapter(). If aac_init_adapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member. After the hardware-specific init function returns an error, aac_probe_one() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-46673 CVE - 2024-46673 EulerOS-SA-2024-2953
-
Amazon Linux 2023: CVE-2024-46689: Medium priority package update for kernel (Multiple Advisories)
Amazon Linux 2023: CVE-2024-46689: Medium priority package update for kernel (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 09/13/2024 Created 02/14/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: soc: qcom: cmd-db: Map shared memory as WC, not WB Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone. The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings. Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC. I tested this on SA8155P with Xen. Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-109-118-189 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-46689 CVE - 2024-46689 https://alas.aws.amazon.com/AL2023/ALAS-2024-713.html https://alas.aws.amazon.com/AL2023/ALAS-2024-779.html
-
Oracle Linux: CVE-2024-46677: ELSA-2024-12813: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-46677: ELSA-2024-12813: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 09/13/2024 Created 11/23/2024 Added 11/21/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: gtp: fix a potential NULL pointer dereference When sockfd_lookup() fails, gtp_encap_enable_socket() returns a NULL pointer, but its callers only check for error pointers thus miss the NULL pointer case. Fix it by returning an error pointer with the error code carried from sockfd_lookup(). (I found this bug during code inspection.) Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-46677 CVE - 2024-46677 ELSA-2024-12813 ELSA-2024-12815 ELSA-2024-12868
-
Oracle Linux: CVE-2024-46674: ELSA-2024-12813: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-46674: ELSA-2024-12813: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 09/13/2024 Created 11/23/2024 Added 11/21/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: st: fix probed platform device ref count on probe error path The probe function never performs any paltform device allocation, thus error path "undo_platform_dev_alloc" is entirely bogus.It drops the reference count from the platform device being probed.If error path is triggered, this will lead to unbalanced device reference counts and premature release of device resources, thus possible use-after-free when releasing remaining devm-managed resources. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-46674 CVE - 2024-46674 ELSA-2024-12813 ELSA-2024-12815 ELSA-2024-12868
-
Ubuntu: (Multiple Advisories) (CVE-2024-46695): Linux kernel vulnerabilities
Ubuntu: (Multiple Advisories) (CVE-2024-46695): Linux kernel vulnerabilities Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:C/A:N) Published 09/13/2024 Created 12/14/2024 Added 12/13/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: selinux,smack: don't bypass permissions check in inode_setsecctx hook Marek Gresko reports that the root user on an NFS client is able to change the security labels on files on an NFS filesystem that is exported with root squashing enabled. The end of the kerneldoc comment for __vfs_setxattr_noperm() states: *This function requires the caller to lock the inode's i_mutex before it *is executed. It also assumes that the caller will make the appropriate *permission checks. nfsd_setattr() does do permissions checking via fh_verify() and nfsd_permission(), but those don't do all the same permissions checks that are done by security_inode_setxattr() and its related LSM hooks do. Since nfsd_setattr() is the only consumer of security_inode_setsecctx(), simplest solution appears to be to replace the call to __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked().This fixes the above issue and has the added benefit of causing nfsd to recall conflicting delegations on a file when a client tries to change its security label. Solution(s) ubuntu-upgrade-linux-image-5-15-0-1039-xilinx-zynqmp ubuntu-upgrade-linux-image-5-15-0-1056-gkeop ubuntu-upgrade-linux-image-5-15-0-1066-ibm ubuntu-upgrade-linux-image-5-15-0-1066-raspi ubuntu-upgrade-linux-image-5-15-0-1068-nvidia ubuntu-upgrade-linux-image-5-15-0-1068-nvidia-lowlatency ubuntu-upgrade-linux-image-5-15-0-1070-gke ubuntu-upgrade-linux-image-5-15-0-1070-kvm ubuntu-upgrade-linux-image-5-15-0-1071-intel-iotg ubuntu-upgrade-linux-image-5-15-0-1071-oracle ubuntu-upgrade-linux-image-5-15-0-1072-gcp ubuntu-upgrade-linux-image-5-15-0-1073-aws ubuntu-upgrade-linux-image-5-15-0-1078-azure ubuntu-upgrade-linux-image-5-15-0-127-generic ubuntu-upgrade-linux-image-5-15-0-127-generic-64k ubuntu-upgrade-linux-image-5-15-0-127-generic-lpae ubuntu-upgrade-linux-image-5-15-0-127-lowlatency ubuntu-upgrade-linux-image-5-15-0-127-lowlatency-64k ubuntu-upgrade-linux-image-6-8-0-1002-gkeop ubuntu-upgrade-linux-image-6-8-0-1015-gke ubuntu-upgrade-linux-image-6-8-0-1016-raspi ubuntu-upgrade-linux-image-6-8-0-1017-ibm ubuntu-upgrade-linux-image-6-8-0-1017-oracle ubuntu-upgrade-linux-image-6-8-0-1017-oracle-64k ubuntu-upgrade-linux-image-6-8-0-1018-oem ubuntu-upgrade-linux-image-6-8-0-1019-gcp ubuntu-upgrade-linux-image-6-8-0-1019-nvidia ubuntu-upgrade-linux-image-6-8-0-1019-nvidia-64k ubuntu-upgrade-linux-image-6-8-0-1019-nvidia-lowlatency ubuntu-upgrade-linux-image-6-8-0-1019-nvidia-lowlatency-64k ubuntu-upgrade-linux-image-6-8-0-1020-aws ubuntu-upgrade-linux-image-6-8-0-1020-azure ubuntu-upgrade-linux-image-6-8-0-1020-azure-fde ubuntu-upgrade-linux-image-6-8-0-50-generic ubuntu-upgrade-linux-image-6-8-0-50-generic-64k ubuntu-upgrade-linux-image-6-8-0-50-lowlatency ubuntu-upgrade-linux-image-6-8-0-50-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-aws-lts-22-04 ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-cvm ubuntu-upgrade-linux-image-azure-fde ubuntu-upgrade-linux-image-azure-lts-22-04 ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-gcp-lts-22-04 ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-20-04 ubuntu-upgrade-linux-image-generic-64k-hwe-22-04 ubuntu-upgrade-linux-image-generic-64k-hwe-24-04 ubuntu-upgrade-linux-image-generic-hwe-20-04 ubuntu-upgrade-linux-image-generic-hwe-22-04 ubuntu-upgrade-linux-image-generic-hwe-24-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-generic-lpae-hwe-20-04 ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-gke-5-15 ubuntu-upgrade-linux-image-gkeop ubuntu-upgrade-linux-image-gkeop-5-15 ubuntu-upgrade-linux-image-gkeop-6-8 ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-classic ubuntu-upgrade-linux-image-ibm-lts-24-04 ubuntu-upgrade-linux-image-intel ubuntu-upgrade-linux-image-intel-iotg ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-64k ubuntu-upgrade-linux-image-lowlatency-64k-hwe-20-04 ubuntu-upgrade-linux-image-lowlatency-64k-hwe-22-04 ubuntu-upgrade-linux-image-lowlatency-64k-hwe-24-04 ubuntu-upgrade-linux-image-lowlatency-hwe-20-04 ubuntu-upgrade-linux-image-lowlatency-hwe-22-04 ubuntu-upgrade-linux-image-lowlatency-hwe-24-04 ubuntu-upgrade-linux-image-nvidia ubuntu-upgrade-linux-image-nvidia-6-8 ubuntu-upgrade-linux-image-nvidia-64k ubuntu-upgrade-linux-image-nvidia-64k-6-8 ubuntu-upgrade-linux-image-nvidia-64k-hwe-22-04 ubuntu-upgrade-linux-image-nvidia-hwe-22-04 ubuntu-upgrade-linux-image-nvidia-lowlatency ubuntu-upgrade-linux-image-nvidia-lowlatency-64k ubuntu-upgrade-linux-image-oem-20-04 ubuntu-upgrade-linux-image-oem-20-04b ubuntu-upgrade-linux-image-oem-20-04c ubuntu-upgrade-linux-image-oem-20-04d ubuntu-upgrade-linux-image-oem-22-04 ubuntu-upgrade-linux-image-oem-22-04a ubuntu-upgrade-linux-image-oem-22-04b ubuntu-upgrade-linux-image-oem-22-04c ubuntu-upgrade-linux-image-oem-22-04d ubuntu-upgrade-linux-image-oem-24-04 ubuntu-upgrade-linux-image-oem-24-04a ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-64k ubuntu-upgrade-linux-image-oracle-lts-22-04 ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-nolpae ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-20-04 ubuntu-upgrade-linux-image-virtual-hwe-22-04 ubuntu-upgrade-linux-image-virtual-hwe-24-04 ubuntu-upgrade-linux-image-xilinx-zynqmp References https://attackerkb.com/topics/cve-2024-46695 CVE - 2024-46695 USN-7154-1 USN-7154-2 USN-7155-1 USN-7156-1 USN-7166-1 USN-7166-2 USN-7166-3 USN-7166-4 USN-7186-1 USN-7186-2 USN-7194-1 USN-7196-1 View more
-
Amazon Linux 2023: CVE-2024-46711: Medium priority package update for kernel (Multiple Advisories)
Amazon Linux 2023: CVE-2024-46711: Medium priority package update for kernel (Multiple Advisories) Severity 4 CVSS (AV:L/AC:H/Au:S/C:N/I:N/A:C) Published 09/13/2024 Created 02/14/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix ID 0 endp usage after multiple re-creations 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-109-118-189 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-46711 CVE - 2024-46711 https://alas.aws.amazon.com/AL2023/ALAS-2024-713.html https://alas.aws.amazon.com/AL2023/ALAS-2024-779.html
-
Ubuntu: (Multiple Advisories) (CVE-2024-46701): Linux kernel vulnerabilities
Ubuntu: (Multiple Advisories) (CVE-2024-46701): Linux kernel vulnerabilities Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 09/13/2024 Created 12/14/2024 Added 12/13/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: libfs: fix infinite directory reads for offset dir After we switch tmpfs dir operations from simple_dir_operations to simple_offset_dir_operations, every rename happened will fill new dentry to dest dir's maple tree(&SHMEM_I(inode)->dir_offsets->mt) with a free key starting with octx->newx_offset, and then set newx_offset equals to free key + 1. This will lead to infinite readdir combine with rename happened at the same time, which fail generic/736 in xfstests(detail show as below). 1. create 5000 files(1 2 3...) under one dir 2. call readdir(man 3 readdir) once, and get one entry 3. rename(entry, "TEMPFILE"), then rename("TEMPFILE", entry) 4. loop 2~3, until readdir return nothing or we loop too many times(tmpfs break test with the second condition) We choose the same logic what commit 9b378f6ad48cf ("btrfs: fix infinite directory reads") to fix it, record the last_index when we open dir, and do not emit the entry which index >= last_index. The file->private_data now used in offset dir can use directly to do this, and we also update the last_index when we llseek the dir file. [brauner: only update last_index after seek when offset is zero like Jan suggested] Solution(s) ubuntu-upgrade-linux-image-6-8-0-1002-gkeop ubuntu-upgrade-linux-image-6-8-0-1015-gke ubuntu-upgrade-linux-image-6-8-0-1016-raspi ubuntu-upgrade-linux-image-6-8-0-1017-ibm ubuntu-upgrade-linux-image-6-8-0-1017-oracle ubuntu-upgrade-linux-image-6-8-0-1017-oracle-64k ubuntu-upgrade-linux-image-6-8-0-1018-oem ubuntu-upgrade-linux-image-6-8-0-1019-gcp ubuntu-upgrade-linux-image-6-8-0-1019-nvidia ubuntu-upgrade-linux-image-6-8-0-1019-nvidia-64k ubuntu-upgrade-linux-image-6-8-0-1019-nvidia-lowlatency ubuntu-upgrade-linux-image-6-8-0-1019-nvidia-lowlatency-64k ubuntu-upgrade-linux-image-6-8-0-1020-aws ubuntu-upgrade-linux-image-6-8-0-1020-azure ubuntu-upgrade-linux-image-6-8-0-1020-azure-fde ubuntu-upgrade-linux-image-6-8-0-50-generic ubuntu-upgrade-linux-image-6-8-0-50-generic-64k ubuntu-upgrade-linux-image-6-8-0-50-lowlatency ubuntu-upgrade-linux-image-6-8-0-50-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-fde ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-22-04 ubuntu-upgrade-linux-image-generic-64k-hwe-24-04 ubuntu-upgrade-linux-image-generic-hwe-22-04 ubuntu-upgrade-linux-image-generic-hwe-24-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-gkeop ubuntu-upgrade-linux-image-gkeop-6-8 ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-classic ubuntu-upgrade-linux-image-ibm-lts-24-04 ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-64k ubuntu-upgrade-linux-image-lowlatency-64k-hwe-22-04 ubuntu-upgrade-linux-image-lowlatency-64k-hwe-24-04 ubuntu-upgrade-linux-image-lowlatency-hwe-22-04 ubuntu-upgrade-linux-image-lowlatency-hwe-24-04 ubuntu-upgrade-linux-image-nvidia ubuntu-upgrade-linux-image-nvidia-6-8 ubuntu-upgrade-linux-image-nvidia-64k ubuntu-upgrade-linux-image-nvidia-64k-6-8 ubuntu-upgrade-linux-image-nvidia-64k-hwe-22-04 ubuntu-upgrade-linux-image-nvidia-hwe-22-04 ubuntu-upgrade-linux-image-nvidia-lowlatency ubuntu-upgrade-linux-image-nvidia-lowlatency-64k ubuntu-upgrade-linux-image-oem-22-04 ubuntu-upgrade-linux-image-oem-22-04a ubuntu-upgrade-linux-image-oem-22-04b ubuntu-upgrade-linux-image-oem-22-04c ubuntu-upgrade-linux-image-oem-22-04d ubuntu-upgrade-linux-image-oem-24-04 ubuntu-upgrade-linux-image-oem-24-04a ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-64k ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-22-04 ubuntu-upgrade-linux-image-virtual-hwe-24-04 References https://attackerkb.com/topics/cve-2024-46701 CVE - 2024-46701 USN-7154-1 USN-7154-2 USN-7155-1 USN-7156-1 USN-7196-1
-
Huawei EulerOS: CVE-2024-46673: kernel security update
Huawei EulerOS: CVE-2024-46673: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 09/13/2024 Created 01/23/2025 Added 01/21/2025 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: scsi: aacraid: Fix double-free on probe failure aac_probe_one() calls hardware-specific init functions through the aac_driver_ident::init pointer, all of which eventually call down to aac_init_adapter(). If aac_init_adapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member. After the hardware-specific init function returns an error, aac_probe_one() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free. Solution(s) huawei-euleros-2_0_sp8-upgrade-bpftool huawei-euleros-2_0_sp8-upgrade-kernel huawei-euleros-2_0_sp8-upgrade-kernel-devel huawei-euleros-2_0_sp8-upgrade-kernel-headers huawei-euleros-2_0_sp8-upgrade-kernel-tools huawei-euleros-2_0_sp8-upgrade-kernel-tools-libs huawei-euleros-2_0_sp8-upgrade-perf huawei-euleros-2_0_sp8-upgrade-python-perf huawei-euleros-2_0_sp8-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-46673 CVE - 2024-46673 EulerOS-SA-2025-1123
-
Debian: CVE-2024-46710: linux, linux-6.1 -- security update
Debian: CVE-2024-46710: linux, linux-6.1 -- security update Severity 4 CVSS (AV:L/AC:M/Au:S/C:N/I:N/A:C) Published 09/13/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Prevent unmapping active read buffers The kms paths keep a persistent map active to read and compare the cursor buffer. These maps can race with each other in simple scenario where: a) buffer "a" mapped for update b) buffer "a" mapped for compare c) do the compare d) unmap "a" for compare e) update the cursor f) unmap "a" for update At step "e" the buffer has been unmapped and the read contents is bogus. Prevent unmapping of active read buffers by simply keeping a count of how many paths have currently active maps and unmap only when the count reaches 0. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-46710 CVE - 2024-46710 DLA-4008-1