ISHACK AI BOT

Amazon Linux AMI 2: CVE-2023-52913: Security patch for kernel (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 08/21/2024 Created 12/21/2024 Added 12/20/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix potential context UAFs gem_context_register() makes the context visible to userspace, and which point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl. So we need to ensure that nothing uses the ctx ptr after this.And we need to ensure that adding the ctx to the xarray is the *last* thing that gem_context_register() does with the ctx pointer. [tursulin: Stable and fixes tags add/tidy.] (cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c) Solution(s) amazon-linux-ami-2-upgrade-bpftool amazon-linux-ami-2-upgrade-bpftool-debuginfo amazon-linux-ami-2-upgrade-kernel amazon-linux-ami-2-upgrade-kernel-debuginfo amazon-linux-ami-2-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-ami-2-upgrade-kernel-debuginfo-common-x86_64 amazon-linux-ami-2-upgrade-kernel-devel amazon-linux-ami-2-upgrade-kernel-headers amazon-linux-ami-2-upgrade-kernel-livepatch-5-15-173-118-169 amazon-linux-ami-2-upgrade-kernel-tools amazon-linux-ami-2-upgrade-kernel-tools-debuginfo amazon-linux-ami-2-upgrade-kernel-tools-devel amazon-linux-ami-2-upgrade-perf amazon-linux-ami-2-upgrade-perf-debuginfo amazon-linux-ami-2-upgrade-python-perf amazon-linux-ami-2-upgrade-python-perf-debuginfo References https://attackerkb.com/topics/cve-2023-52913 AL2/ALASKERNEL-5.15-2024-059 AL2/ALASKERNEL-5.15-2025-060 CVE - 2023-52913

Joomla!: [20240802] - Core - Cache Poisoning in Pagination (CVE-2024-27185) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 08/21/2024 Created 08/22/2024 Added 08/21/2024 Modified 08/22/2024 Description The pagination class includes arbitrary parameters in links, leading to cache poisoning attack vectors. Solution(s) joomla-upgrade-3_10_17 joomla-upgrade-4_4_7 joomla-upgrade-5_1_3 References https://attackerkb.com/topics/cve-2024-27185 CVE - 2024-27185 http://developer.joomla.org/security-centre/942-20240802-core-cache-poisoning-in-pagination.html

Joomla!: [20240805] - Core - XSS vectors in Outputfilter::strip* methods (CVE-2024-40743) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 08/21/2024 Created 08/22/2024 Added 08/21/2024 Modified 08/22/2024 Description The stripImages and stripIframes methods didn't properly process inputs, leading to XSS vectors. Solution(s) joomla-upgrade-3_10_17 joomla-upgrade-4_4_7 joomla-upgrade-5_1_3 References https://attackerkb.com/topics/cve-2024-40743 CVE - 2024-40743 http://developer.joomla.org/security-centre/946-20240805-core-xss-vectors-in-outputfilter-strip-methods.html

Huawei EulerOS: CVE-2024-43882: kernel security update Severity 7 CVSS (AV:L/AC:M/Au:S/C:C/I:C/A:C) Published 08/21/2024 Created 01/23/2025 Added 01/21/2025 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: exec: Fix ToCToU between perm check and set-uid/gid usage When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug7 13:16 target But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root". Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal. 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-43882 CVE - 2024-43882 EulerOS-SA-2025-1123

Red Hat: CVE-2024-43871: kernel: devres: Fix memory leakage caused by driver API devm_free_percpu() (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 08/21/2024 Created 09/26/2024 Added 09/25/2024 Modified 09/25/2024 Description In the Linux kernel, the following vulnerability has been resolved: devres: Fix memory leakage caused by driver API devm_free_percpu() It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu(). Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-43871 RHSA-2024:7000 RHSA-2024:7001

Ubuntu: (Multiple Advisories) (CVE-2024-43881): Linux kernel vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 08/21/2024 Created 12/14/2024 Added 12/13/2024 Modified 01/10/2025 Description In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: change DMA direction while mapping reinjected packets For fragmented packets, ath12k reassembles each fragment as a normal packet and then reinjects it into HW ring. In this case, the DMA direction should be DMA_TO_DEVICE, not DMA_FROM_DEVICE. Otherwise, an invalid payload may be reinjected into the HW and subsequently delivered to the host. Given that arbitrary memory can be allocated to the skb buffer, knowledge about the data contained in the reinjected buffer is lacking. Consequently, there’s a risk of private information being leaked. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1 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-43881 CVE - 2024-43881 USN-7154-1 USN-7154-2 USN-7155-1 USN-7156-1 USN-7196-1

VMware Photon OS: CVE-2024-43879 Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 08/21/2024 Created 01/21/2025 Added 01/20/2025 Modified 01/20/2025 Description In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he() Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning: kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-43879 CVE - 2024-43879

Huawei EulerOS: CVE-2024-43882: kernel security update Severity 7 CVSS (AV:L/AC:M/Au:S/C:C/I:C/A:C) Published 08/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: exec: Fix ToCToU between perm check and set-uid/gid usage When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug7 13:16 target But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root". Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal. 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-43882 CVE - 2024-43882 EulerOS-SA-2024-2832

VMware Photon OS: CVE-2024-43880 Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 08/21/2024 Created 01/21/2025 Added 01/20/2025 Modified 01/20/2025 Description In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_erp: Fix object nesting warning ACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM (A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can contain more ACLs (i.e., tc filters), but the number of masks in each region (i.e., tc chain) is limited. In order to mitigate the effects of the above limitation, the device allows filters to share a single mask if their masks only differ in up to 8 consecutive bits. For example, dst_ip/25 can be represented using dst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the number of masks being used (and therefore does not support mask aggregation), but can contain a limited number of filters. The driver uses the "objagg" library to perform the mask aggregation by passing it objects that consist of the filter's mask and whether the filter is to be inserted into the A-TCAM or the C-TCAM since filters in different TCAMs cannot share a mask. The set of created objects is dependent on the insertion order of the filters and is not necessarily optimal. Therefore, the driver will periodically ask the library to compute a more optimal set ("hints") by looking at all the existing objects. When the library asks the driver whether two objects can be aggregated the driver only compares the provided masks and ignores the A-TCAM / C-TCAM indication. This is the right thing to do since the goal is to move as many filters as possible to the A-TCAM. The driver also forbids two identical masks from being aggregated since this can only happen if one was intentionally put in the C-TCAM to avoid a conflict in the A-TCAM. The above can result in the following set of hints: H1: {mask X, A-TCAM} -> H2: {mask Y, A-TCAM} // X is Y + delta H3: {mask Y, C-TCAM} -> H4: {mask Z, A-TCAM} // Y is Z + delta After getting the hints from the library the driver will start migrating filters from one region to another while consulting the computed hints and instructing the device to perform a lookup in both regions during the transition. Assuming a filter with mask X is being migrated into the A-TCAM in the new region, the hints lookup will return H1. Since H2 is the parent of H1, the library will try to find the object associated with it and create it if necessary in which case another hints lookup (recursive) will be performed. This hints lookup for {mask Y, A-TCAM} will either return H2 or H3 since the driver passes the library an object comparison function that ignores the A-TCAM / C-TCAM indication. This can eventually lead to nested objects which are not supported by the library [1]. Fix by removing the object comparison function from both the driver and the library as the driver was the only user. That way the lookup will only return exact matches. I do not have a reliable reproducer that can reproduce the issue in a timely manner, but before the fix the issue would reproduce in several minutes and with the fix it does not reproduce in over an hour. Note that the current usefulness of the hints is limited because they include the C-TCAM indication and represent aggregation that cannot actually happen. This will be addressed in net-next. [1] WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0 Modules linked in: CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42 Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:objagg_obj_parent_assign+0xb5/0xd0 [...] Call Trace: <TASK> __objagg_obj_get+0x2bb/0x580 objagg_obj_get+0xe/0x80 mlxsw_sp_acl_erp_mask_get+0xb5/0xf0 mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510 process_one_work+0x151/0x370 Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-43880 CVE - 2024-43880

Alma Linux: CVE-2024-43871: Important: kernel security update (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 08/21/2024 Created 09/27/2024 Added 09/26/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: devres: Fix memory leakage caused by driver API devm_free_percpu() It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu(). Solution(s) alma-upgrade-bpftool alma-upgrade-kernel 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-modules alma-upgrade-kernel-debug-modules-extra alma-upgrade-kernel-devel alma-upgrade-kernel-doc alma-upgrade-kernel-headers alma-upgrade-kernel-modules 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-kvm alma-upgrade-kernel-rt-debug-modules alma-upgrade-kernel-rt-debug-modules-extra alma-upgrade-kernel-rt-devel alma-upgrade-kernel-rt-kvm alma-upgrade-kernel-rt-modules alma-upgrade-kernel-rt-modules-extra alma-upgrade-kernel-tools alma-upgrade-kernel-tools-libs alma-upgrade-kernel-tools-libs-devel alma-upgrade-kernel-zfcpdump alma-upgrade-kernel-zfcpdump-core alma-upgrade-kernel-zfcpdump-devel alma-upgrade-kernel-zfcpdump-modules alma-upgrade-kernel-zfcpdump-modules-extra alma-upgrade-perf alma-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-43871 CVE - 2024-43871 https://errata.almalinux.org/8/ALSA-2024-7000.html https://errata.almalinux.org/8/ALSA-2024-7001.html

Rocky Linux: CVE-2024-43880: kernel-rt (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 08/21/2024 Created 11/21/2024 Added 11/19/2024 Modified 11/19/2024 Description In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_erp: Fix object nesting warning ACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM (A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can contain more ACLs (i.e., tc filters), but the number of masks in each region (i.e., tc chain) is limited. In order to mitigate the effects of the above limitation, the device allows filters to share a single mask if their masks only differ in up to 8 consecutive bits. For example, dst_ip/25 can be represented using dst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the number of masks being used (and therefore does not support mask aggregation), but can contain a limited number of filters. The driver uses the "objagg" library to perform the mask aggregation by passing it objects that consist of the filter's mask and whether the filter is to be inserted into the A-TCAM or the C-TCAM since filters in different TCAMs cannot share a mask. The set of created objects is dependent on the insertion order of the filters and is not necessarily optimal. Therefore, the driver will periodically ask the library to compute a more optimal set ("hints") by looking at all the existing objects. When the library asks the driver whether two objects can be aggregated the driver only compares the provided masks and ignores the A-TCAM / C-TCAM indication. This is the right thing to do since the goal is to move as many filters as possible to the A-TCAM. The driver also forbids two identical masks from being aggregated since this can only happen if one was intentionally put in the C-TCAM to avoid a conflict in the A-TCAM. The above can result in the following set of hints: H1: {mask X, A-TCAM} -> H2: {mask Y, A-TCAM} // X is Y + delta H3: {mask Y, C-TCAM} -> H4: {mask Z, A-TCAM} // Y is Z + delta After getting the hints from the library the driver will start migrating filters from one region to another while consulting the computed hints and instructing the device to perform a lookup in both regions during the transition. Assuming a filter with mask X is being migrated into the A-TCAM in the new region, the hints lookup will return H1. Since H2 is the parent of H1, the library will try to find the object associated with it and create it if necessary in which case another hints lookup (recursive) will be performed. This hints lookup for {mask Y, A-TCAM} will either return H2 or H3 since the driver passes the library an object comparison function that ignores the A-TCAM / C-TCAM indication. This can eventually lead to nested objects which are not supported by the library [1]. Fix by removing the object comparison function from both the driver and the library as the driver was the only user. That way the lookup will only return exact matches. I do not have a reliable reproducer that can reproduce the issue in a timely manner, but before the fix the issue would reproduce in several minutes and with the fix it does not reproduce in over an hour. Note that the current usefulness of the hints is limited because they include the C-TCAM indication and represent aggregation that cannot actually happen. This will be addressed in net-next. [1] WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0 Modules linked in: CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42 Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:objagg_obj_parent_assign+0xb5/0xd0 [...] Call Trace: <TASK> __objagg_obj_get+0x2bb/0x580 objagg_obj_get+0xe/0x80 mlxsw_sp_acl_erp_mask_get+0xb5/0xf0 mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510 process_one_work+0x151/0x370 Solution(s) rocky-upgrade-bpftool rocky-upgrade-bpftool-debuginfo rocky-upgrade-kernel rocky-upgrade-kernel-core rocky-upgrade-kernel-cross-headers rocky-upgrade-kernel-debug rocky-upgrade-kernel-debug-core rocky-upgrade-kernel-debug-debuginfo rocky-upgrade-kernel-debug-devel rocky-upgrade-kernel-debug-modules rocky-upgrade-kernel-debug-modules-extra rocky-upgrade-kernel-debuginfo rocky-upgrade-kernel-debuginfo-common-x86_64 rocky-upgrade-kernel-devel rocky-upgrade-kernel-headers rocky-upgrade-kernel-modules rocky-upgrade-kernel-modules-extra rocky-upgrade-kernel-rt rocky-upgrade-kernel-rt-core rocky-upgrade-kernel-rt-debug rocky-upgrade-kernel-rt-debug-core rocky-upgrade-kernel-rt-debug-debuginfo rocky-upgrade-kernel-rt-debug-devel rocky-upgrade-kernel-rt-debug-kvm rocky-upgrade-kernel-rt-debug-modules rocky-upgrade-kernel-rt-debug-modules-extra rocky-upgrade-kernel-rt-debuginfo rocky-upgrade-kernel-rt-debuginfo-common-x86_64 rocky-upgrade-kernel-rt-devel rocky-upgrade-kernel-rt-kvm rocky-upgrade-kernel-rt-modules rocky-upgrade-kernel-rt-modules-extra rocky-upgrade-kernel-tools rocky-upgrade-kernel-tools-debuginfo rocky-upgrade-kernel-tools-libs rocky-upgrade-kernel-tools-libs-devel rocky-upgrade-perf rocky-upgrade-perf-debuginfo rocky-upgrade-python3-perf rocky-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-43880 CVE - 2024-43880 https://errata.rockylinux.org/RLSA-2024:8856 https://errata.rockylinux.org/RLSA-2024:8870

VMware Photon OS: CVE-2024-43882 Severity 7 CVSS (AV:L/AC:L/Au:N/C:C/I:C/A:C) Published 08/21/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: exec: Fix ToCToU between perm check and set-uid/gid usage When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug7 13:16 target But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root". Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-43882 CVE - 2024-43882

Huawei EulerOS: CVE-2024-43871: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 08/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: devres: Fix memory leakage caused by driver API devm_free_percpu() It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu(). 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-43871 CVE - 2024-43871 EulerOS-SA-2024-2907

Huawei EulerOS: CVE-2022-48899: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:S/C:N/I:N/A:C) Published 08/21/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/virtio: Fix GEM handle creation UAF Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference.For that reason, dropping the handle's reference must be done *after* we are done dereferencing the object. 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-2022-48899 CVE - 2022-48899 EulerOS-SA-2024-2815

Huawei EulerOS: CVE-2024-43882: kernel security update Severity 7 CVSS (AV:L/AC:M/Au:S/C:C/I:C/A:C) Published 08/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: exec: Fix ToCToU between perm check and set-uid/gid usage When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug7 13:16 target But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root". Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal. 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-43882 CVE - 2024-43882 EulerOS-SA-2024-2907

Ubuntu: (CVE-2023-52910): linux vulnerability Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 08/21/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: iommu/iova: Fix alloc iova overflows issue In __alloc_and_insert_iova_range, there is an issue that retry_pfn overflows. The value of iovad->anchor.pfn_hi is ~0UL, then when iovad->cached_node is iovad->anchor, curr_iova->pfn_hi + 1 will overflow. As a result, if the retry logic is executed, low_pfn is updated to 0, and then new_pfn < low_pfn returns false to make the allocation successful. This issue occurs in the following two situations: 1. The first iova size exceeds the domain size. When initializing iova domain, iovad->cached_node is assigned as iovad->anchor. For example, the iova domain size is 10M, start_pfn is 0x1_F000_0000, and the iova size allocated for the first time is 11M. The following is the log information, new->pfn_lo is smaller than iovad->cached_node. Example log as follows: [223.798112][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range start_pfn:0x1f0000,retry_pfn:0x0,size:0xb00,limit_pfn:0x1f0a00 [223.799590][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range success start_pfn:0x1f0000,new->pfn_lo:0x1efe00,new->pfn_hi:0x1f08ff 2. The node with the largest iova->pfn_lo value in the iova domain is deleted, iovad->cached_node will be updated to iovad->anchor, and then the alloc iova size exceeds the maximum iova size that can be allocated in the domain. After judging that retry_pfn is less than limit_pfn, call retry_pfn+1 to fix the overflow issue. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-15 ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-5-15 ubuntu-upgrade-linux-azure-fde ubuntu-upgrade-linux-azure-fde-5-15 ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-5-15 ubuntu-upgrade-linux-gke ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-gkeop-5-15 ubuntu-upgrade-linux-hwe-5-15 ubuntu-upgrade-linux-ibm ubuntu-upgrade-linux-intel-iot-realtime ubuntu-upgrade-linux-intel-iotg ubuntu-upgrade-linux-intel-iotg-5-15 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-lowlatency ubuntu-upgrade-linux-lowlatency-hwe-5-15 ubuntu-upgrade-linux-nvidia ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-15 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-realtime ubuntu-upgrade-linux-riscv-5-15 References https://attackerkb.com/topics/cve-2023-52910 CVE - 2023-52910 https://git.kernel.org/linus/dcdb3ba7e2a8caae7bfefd603bc22fd0ce9a389c https://git.kernel.org/stable/c/61cbf790e7329ed78877560be7136f0b911bba7f https://git.kernel.org/stable/c/c929a230c84441e400c32e7b7b4ab763711fb63e https://git.kernel.org/stable/c/dcdb3ba7e2a8caae7bfefd603bc22fd0ce9a389c https://www.cve.org/CVERecord?id=CVE-2023-52910

Microsoft Edge Chromium: CVE-2024-7978 Insufficient policy enforcement in Data Transfer Severity 4 CVSS (AV:N/AC:M/Au:N/C:P/I:N/A:N) Published 08/21/2024 Created 08/24/2024 Added 08/23/2024 Modified 01/28/2025 Description Insufficient policy enforcement in Data Transfer in Google Chrome prior to 128.0.6613.84 allowed a remote attacker who convinced a user to engage in specific UI gestures to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) Solution(s) microsoft-edge-upgrade-latest References https://attackerkb.com/topics/cve-2024-7978 CVE - 2024-7978 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-7978

Huawei EulerOS: CVE-2024-43863: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 08/21/2024 Created 12/13/2024 Added 12/12/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a deadlock in dma buf fence polling Introduce a version of the fence ops that on release doesn't remove the fence from the pending list, and thus doesn't require a lock to fix poll->fence wait->fence unref deadlocks. vmwgfx overwrites the wait callback to iterate over the list of all fences and update their status, to do that it holds a lock to prevent the list modifcations from other threads. The fence destroy callback both deletes the fence and removes it from the list of pending fences, for which it holds a lock. dma buf polling cb unrefs a fence after it's been signaled: so the poll calls the wait, which signals the fences, which are being destroyed. The destruction tries to acquire the lock on the pending fences list which it can never get because it's held by the wait from which it was called. Old bug, but not a lot of userspace apps were using dma-buf polling interfaces. Fix those, in particular this fixes KDE stalls/deadlock. Solution(s) huawei-euleros-2_0_sp11-upgrade-bpftool huawei-euleros-2_0_sp11-upgrade-kernel huawei-euleros-2_0_sp11-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp11-upgrade-kernel-tools huawei-euleros-2_0_sp11-upgrade-kernel-tools-libs huawei-euleros-2_0_sp11-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-43863 CVE - 2024-43863 EulerOS-SA-2024-2983

FreeBSD: VID-49EF501C-62B6-11EF-BBA5-2CF05DA270F3 (CVE-2024-7110): Gitlab -- vulnerabilities Severity 7 CVSS (AV:N/AC:H/Au:S/C:C/I:C/A:N) Published 08/21/2024 Created 08/27/2024 Added 08/25/2024 Modified 01/28/2025 Description An issue was discovered in GitLab EE affecting all versions starting 17.0 to 17.1.6, 17.2 prior to 17.2.4, and 17.3 prior to 17.3.1 allows an attacker to execute arbitrary command in a victim's pipeline through prompt injection. Solution(s) freebsd-upgrade-package-gitlab-ce freebsd-upgrade-package-gitlab-ee References CVE-2024-7110

Debian: CVE-2024-8033: chromium -- security update Severity 4 CVSS (AV:N/AC:M/Au:N/C:N/I:P/A:N) Published 08/21/2024 Created 08/27/2024 Added 08/26/2024 Modified 01/28/2025 Description Inappropriate implementation in WebApp Installs in Google Chrome on Windows prior to 128.0.6613.84 allowed an attacker who convinced a user to install a malicious application to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low) Solution(s) debian-upgrade-chromium References https://attackerkb.com/topics/cve-2024-8033 CVE - 2024-8033 DSA-5757-1

Microsoft Edge Chromium: CVE-2024-7975 Inappropriate implementation in Permissions Severity 4 CVSS (AV:N/AC:M/Au:N/C:N/I:P/A:N) Published 08/21/2024 Created 08/24/2024 Added 08/23/2024 Modified 01/28/2025 Description Inappropriate implementation in Permissions in Google Chrome prior to 128.0.6613.84 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium) Solution(s) microsoft-edge-upgrade-latest References https://attackerkb.com/topics/cve-2024-7975 CVE - 2024-7975 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-7975

FreeBSD: VID-B339992E-6059-11EF-8A0F-A8A1599412C6 (CVE-2024-7973): chromium -- multiple security fixes Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 08/21/2024 Created 08/24/2024 Added 08/22/2024 Modified 01/28/2025 Description Heap buffer overflow in PDFium in Google Chrome prior to 128.0.6613.84 allowed a remote attacker to perform an out of bounds memory read via a crafted PDF file. (Chromium security severity: Medium) Solution(s) freebsd-upgrade-package-chromium freebsd-upgrade-package-ungoogled-chromium References CVE-2024-7973

FreeBSD: VID-B339992E-6059-11EF-8A0F-A8A1599412C6 (CVE-2024-7977): chromium -- multiple security fixes Severity 7 CVSS (AV:L/AC:M/Au:N/C:C/I:C/A:C) Published 08/21/2024 Created 08/24/2024 Added 08/22/2024 Modified 01/28/2025 Description Insufficient data validation in Installer in Google Chrome on Windows prior to 128.0.6613.84 allowed a local attacker to perform privilege escalation via a malicious file. (Chromium security severity: Medium) Solution(s) freebsd-upgrade-package-chromium freebsd-upgrade-package-ungoogled-chromium References CVE-2024-7977

FreeBSD: VID-B339992E-6059-11EF-8A0F-A8A1599412C6 (CVE-2024-7972): chromium -- multiple security fixes Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 08/21/2024 Created 08/24/2024 Added 08/22/2024 Modified 01/28/2025 Description Inappropriate implementation in V8 in Google Chrome prior to 128.0.6613.84 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page. (Chromium security severity: Medium) Solution(s) freebsd-upgrade-package-chromium freebsd-upgrade-package-ungoogled-chromium References CVE-2024-7972

FreeBSD: VID-B339992E-6059-11EF-8A0F-A8A1599412C6 (CVE-2024-7980): chromium -- multiple security fixes Severity 7 CVSS (AV:L/AC:M/Au:N/C:C/I:C/A:C) Published 08/21/2024 Created 08/24/2024 Added 08/22/2024 Modified 01/28/2025 Description Insufficient data validation in Installer in Google Chrome on Windows prior to 128.0.6613.84 allowed a local attacker to perform privilege escalation via a crafted symbolic link. (Chromium security severity: Medium) Solution(s) freebsd-upgrade-package-chromium freebsd-upgrade-package-ungoogled-chromium References CVE-2024-7980