ISHACK AI BOT

Red Hat: CVE-2024-41009: kernel: bpf: Fix overrunning reservations in ringbuf (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 07/17/2024 Created 11/07/2024 Added 11/06/2024 Modified 02/10/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter. Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-41009 RHSA-2024:10262 RHSA-2024:10274 RHSA-2024:10771 RHSA-2024:10772 RHSA-2024:10773 RHSA-2024:8856 RHSA-2024:8870 View more

Google Chrome Vulnerability: CVE-2024-6779 Out of bounds memory access in V8 Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 07/17/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description Out of bounds memory access in V8 in Google Chrome prior to 126.0.6478.182 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High) Solution(s) google-chrome-upgrade-latest References https://attackerkb.com/topics/cve-2024-6779 CVE - 2024-6779

Oracle WebLogic: CVE-2023-7272 : Critical Patch Update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/17/2024 Created 01/23/2025 Added 01/21/2025 Modified 02/10/2025 Description In Eclipse Parsson before 1.0.4 and 1.1.3, a document with a large depth of nested objects can allow an attacker to cause a Java stack overflow exception and denial of service. Eclipse Parsson allows processing (e.g. parse, generate, transform and query) JSON documents. Solution(s) oracle-weblogic-jan-2025-cpu-12_2_1_4_0 oracle-weblogic-jan-2025-cpu-14_1_1_0_0 References https://attackerkb.com/topics/cve-2023-7272 CVE - 2023-7272 http://www.oracle.com/security-alerts/cpujan2025.html https://support.oracle.com/rs?type=doc&id=3064245.2

OS X update for Photos (CVE-2023-42949) Severity 2 CVSS (AV:L/AC:L/Au:S/C:P/I:N/A:N) Published 07/17/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description This issue was addressed with improved data protection. This issue is fixed in iOS 17 and iPadOS 17, macOS Sonoma 14, watchOS 10, tvOS 17. An app may be able to access edited photos saved to a temporary directory. Solution(s) apple-osx-upgrade-14 References https://attackerkb.com/topics/cve-2023-42949 CVE - 2023-42949 https://support.apple.com/kb/HT213940

Google Chrome Vulnerability: CVE-2024-6775 Use after free in Media Stream Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 07/17/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description Use after free in Media Stream in Google Chrome prior to 126.0.6478.182 allowed a remote attacker who convinced a user to engage in specific UI gestures to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) Solution(s) google-chrome-upgrade-latest References https://attackerkb.com/topics/cve-2024-6775 CVE - 2024-6775

Ubuntu: (Multiple Advisories) (CVE-2024-41009): Linux kernel vulnerabilities Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/17/2024 Created 09/20/2024 Added 09/20/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter. Solution(s) ubuntu-upgrade-linux-image-5-15-0-1036-xilinx-zynqmp ubuntu-upgrade-linux-image-5-15-0-1053-gkeop ubuntu-upgrade-linux-image-5-15-0-1063-ibm ubuntu-upgrade-linux-image-5-15-0-1063-raspi ubuntu-upgrade-linux-image-5-15-0-1065-intel-iotg ubuntu-upgrade-linux-image-5-15-0-1065-nvidia ubuntu-upgrade-linux-image-5-15-0-1065-nvidia-lowlatency ubuntu-upgrade-linux-image-5-15-0-1067-gke ubuntu-upgrade-linux-image-5-15-0-1067-kvm ubuntu-upgrade-linux-image-5-15-0-1068-oracle ubuntu-upgrade-linux-image-5-15-0-1069-gcp ubuntu-upgrade-linux-image-5-15-0-1070-aws ubuntu-upgrade-linux-image-5-15-0-1073-azure ubuntu-upgrade-linux-image-5-15-0-1073-azure-fde ubuntu-upgrade-linux-image-5-15-0-122-generic ubuntu-upgrade-linux-image-5-15-0-122-generic-64k ubuntu-upgrade-linux-image-5-15-0-122-generic-lpae ubuntu-upgrade-linux-image-5-15-0-122-lowlatency ubuntu-upgrade-linux-image-5-15-0-122-lowlatency-64k ubuntu-upgrade-linux-image-6-8-0-1002-gkeop ubuntu-upgrade-linux-image-6-8-0-1011-gke ubuntu-upgrade-linux-image-6-8-0-1012-raspi ubuntu-upgrade-linux-image-6-8-0-1013-ibm ubuntu-upgrade-linux-image-6-8-0-1013-oem ubuntu-upgrade-linux-image-6-8-0-1013-oracle ubuntu-upgrade-linux-image-6-8-0-1013-oracle-64k ubuntu-upgrade-linux-image-6-8-0-1014-nvidia ubuntu-upgrade-linux-image-6-8-0-1014-nvidia-64k ubuntu-upgrade-linux-image-6-8-0-1014-nvidia-lowlatency ubuntu-upgrade-linux-image-6-8-0-1014-nvidia-lowlatency-64k ubuntu-upgrade-linux-image-6-8-0-1015-azure ubuntu-upgrade-linux-image-6-8-0-1015-azure-fde ubuntu-upgrade-linux-image-6-8-0-1015-gcp ubuntu-upgrade-linux-image-6-8-0-1016-aws ubuntu-upgrade-linux-image-6-8-0-45-generic ubuntu-upgrade-linux-image-6-8-0-45-generic-64k ubuntu-upgrade-linux-image-6-8-0-45-lowlatency ubuntu-upgrade-linux-image-6-8-0-45-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-fde-lts-22-04 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-hwe-20-04 ubuntu-upgrade-linux-image-lowlatency-hwe-22-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-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-41009 CVE - 2024-41009 USN-7020-1 USN-7020-2 USN-7020-3 USN-7020-4 USN-7021-1 USN-7021-2 USN-7021-3 USN-7021-4 USN-7021-5 USN-7029-1 USN-7156-1 View more

Google Chrome Vulnerability: CVE-2024-6776 Use after free in Audio Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 07/17/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description Use after free in Audio in Google Chrome prior to 126.0.6478.182 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) Solution(s) google-chrome-upgrade-latest References https://attackerkb.com/topics/cve-2024-6776 CVE - 2024-6776

OS X update for MobileStorageMounter (CVE-2023-42958) Severity 7 CVSS (AV:L/AC:M/Au:N/C:C/I:C/A:C) Published 07/17/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Ventura 13.4. An app may be able to gain elevated privileges. Solution(s) apple-osx-upgrade-13_4 References https://attackerkb.com/topics/cve-2023-42958 CVE - 2023-42958 https://support.apple.com/kb/HT213758

SUSE: CVE-2024-41009: SUSE Linux Security Advisory Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/17/2024 Created 08/14/2024 Added 08/14/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter. Solution(s) suse-upgrade-cluster-md-kmp-64kb suse-upgrade-cluster-md-kmp-azure suse-upgrade-cluster-md-kmp-default suse-upgrade-cluster-md-kmp-rt suse-upgrade-dlm-kmp-64kb suse-upgrade-dlm-kmp-azure suse-upgrade-dlm-kmp-default suse-upgrade-dlm-kmp-rt suse-upgrade-dtb-allwinner suse-upgrade-dtb-altera suse-upgrade-dtb-amazon suse-upgrade-dtb-amd suse-upgrade-dtb-amlogic suse-upgrade-dtb-apm suse-upgrade-dtb-apple suse-upgrade-dtb-arm suse-upgrade-dtb-broadcom suse-upgrade-dtb-cavium suse-upgrade-dtb-exynos suse-upgrade-dtb-freescale suse-upgrade-dtb-hisilicon suse-upgrade-dtb-lg suse-upgrade-dtb-marvell suse-upgrade-dtb-mediatek suse-upgrade-dtb-nvidia suse-upgrade-dtb-qcom suse-upgrade-dtb-renesas suse-upgrade-dtb-rockchip suse-upgrade-dtb-socionext suse-upgrade-dtb-sprd suse-upgrade-dtb-xilinx suse-upgrade-gfs2-kmp-64kb suse-upgrade-gfs2-kmp-azure suse-upgrade-gfs2-kmp-default suse-upgrade-gfs2-kmp-rt suse-upgrade-kernel-64kb suse-upgrade-kernel-64kb-devel suse-upgrade-kernel-64kb-extra suse-upgrade-kernel-64kb-livepatch-devel suse-upgrade-kernel-64kb-optional suse-upgrade-kernel-azure suse-upgrade-kernel-azure-devel suse-upgrade-kernel-azure-extra suse-upgrade-kernel-azure-livepatch-devel suse-upgrade-kernel-azure-optional suse-upgrade-kernel-azure-vdso suse-upgrade-kernel-debug suse-upgrade-kernel-debug-devel suse-upgrade-kernel-debug-livepatch-devel suse-upgrade-kernel-debug-vdso suse-upgrade-kernel-default suse-upgrade-kernel-default-base suse-upgrade-kernel-default-base-rebuild suse-upgrade-kernel-default-devel suse-upgrade-kernel-default-extra suse-upgrade-kernel-default-livepatch suse-upgrade-kernel-default-livepatch-devel suse-upgrade-kernel-default-optional suse-upgrade-kernel-default-vdso suse-upgrade-kernel-devel suse-upgrade-kernel-devel-azure suse-upgrade-kernel-devel-rt suse-upgrade-kernel-docs suse-upgrade-kernel-docs-html suse-upgrade-kernel-kvmsmall suse-upgrade-kernel-kvmsmall-devel suse-upgrade-kernel-kvmsmall-livepatch-devel suse-upgrade-kernel-kvmsmall-vdso suse-upgrade-kernel-macros suse-upgrade-kernel-obs-build suse-upgrade-kernel-obs-qa suse-upgrade-kernel-rt suse-upgrade-kernel-rt-devel suse-upgrade-kernel-rt-extra suse-upgrade-kernel-rt-livepatch suse-upgrade-kernel-rt-livepatch-devel suse-upgrade-kernel-rt-optional suse-upgrade-kernel-rt-vdso suse-upgrade-kernel-rt_debug suse-upgrade-kernel-rt_debug-devel suse-upgrade-kernel-rt_debug-livepatch-devel suse-upgrade-kernel-rt_debug-vdso suse-upgrade-kernel-source suse-upgrade-kernel-source-azure suse-upgrade-kernel-source-rt suse-upgrade-kernel-source-vanilla suse-upgrade-kernel-syms suse-upgrade-kernel-syms-azure suse-upgrade-kernel-syms-rt suse-upgrade-kernel-zfcpdump suse-upgrade-kselftests-kmp-64kb suse-upgrade-kselftests-kmp-azure suse-upgrade-kselftests-kmp-default suse-upgrade-kselftests-kmp-rt suse-upgrade-ocfs2-kmp-64kb suse-upgrade-ocfs2-kmp-azure suse-upgrade-ocfs2-kmp-default suse-upgrade-ocfs2-kmp-rt suse-upgrade-reiserfs-kmp-64kb suse-upgrade-reiserfs-kmp-azure suse-upgrade-reiserfs-kmp-default suse-upgrade-reiserfs-kmp-rt References https://attackerkb.com/topics/cve-2024-41009 CVE - 2024-41009

SUSE: CVE-2024-37372: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/17/2024 Created 07/19/2024 Added 07/18/2024 Modified 07/23/2024 Description This CVE is addressed in the SUSE advisories SUSE-SU-2024:2543-1, SUSE-SU-2024:2574-1, CVE-2024-37372. Solution(s) suse-upgrade-corepack20 suse-upgrade-nodejs20 suse-upgrade-nodejs20-devel suse-upgrade-nodejs20-docs suse-upgrade-npm20 References https://attackerkb.com/topics/cve-2024-37372 CVE - 2024-37372 SUSE-SU-2024:2543-1 SUSE-SU-2024:2574-1

OS X update for Maps (CVE-2023-42957) Severity 2 CVSS (AV:L/AC:L/Au:S/C:P/I:N/A:N) Published 07/17/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description A permissions issue was addressed with additional restrictions. This issue is fixed in iOS 17 and iPadOS 17, macOS Sonoma 14, watchOS 10. An app may be able to read sensitive location information. Solution(s) apple-osx-upgrade-14 References https://attackerkb.com/topics/cve-2023-42957 CVE - 2023-42957 https://support.apple.com/kb/HT213940

OS X update for CoreServices (CVE-2023-40398) Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 07/17/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description This issue was addressed with improved checks. This issue is fixed in macOS Monterey 12.6.4, macOS Big Sur 11.7.5, macOS Ventura 13.3, iOS 16.4 and iPadOS 16.4. A sandboxed process may be able to circumvent sandbox restrictions. Solution(s) apple-osx-upgrade-11_7_5 apple-osx-upgrade-12_6_4 apple-osx-upgrade-13_3 References https://attackerkb.com/topics/cve-2023-40398 CVE - 2023-40398 https://support.apple.com/kb/HT213670 https://support.apple.com/kb/HT213675 https://support.apple.com/kb/HT213677

VMware Photon OS: CVE-2024-41009 Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/17/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-41009 CVE - 2024-41009

Oracle Linux: CVE-2024-41009: ELSA-2024-8856:kernel security update (MODERATE) (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 07/17/2024 Created 11/13/2024 Added 11/11/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter. Solution(s) oracle-linux-upgrade-kernel oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-41009 CVE - 2024-41009 ELSA-2024-8856 ELSA-2024-12815 ELSA-2024-10274

Google Chrome Vulnerability: CVE-2024-6773 Type Confusion in V8 Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 07/17/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description Inappropriate implementation in V8 in Google Chrome prior to 126.0.6478.182 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) Solution(s) google-chrome-upgrade-latest References https://attackerkb.com/topics/cve-2024-6773 CVE - 2024-6773

Google Chrome Vulnerability: CVE-2024-6778 Race in DevTools Severity 8 CVSS (AV:N/AC:H/Au:N/C:C/I:C/A:C) Published 07/17/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description Race in DevTools in Google Chrome prior to 126.0.6478.182 allowed an attacker who convinced a user to install a malicious extension to inject scripts or HTML into a privileged page via a crafted Chrome Extension. (Chromium security severity: High) Solution(s) google-chrome-upgrade-latest References https://attackerkb.com/topics/cve-2024-6778 CVE - 2024-6778

OS X update for IOUserEthernet (CVE-2023-40396) Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 07/17/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description The issue was addressed with improved memory handling. This issue is fixed in iOS 17 and iPadOS 17, macOS Sonoma 14, watchOS 10, tvOS 17. An app may be able to execute arbitrary code with kernel privileges. Solution(s) apple-osx-upgrade-14 References https://attackerkb.com/topics/cve-2023-40396 CVE - 2023-40396 https://support.apple.com/kb/HT213940

Alma Linux: CVE-2024-41009: Moderate: kernel security update (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/17/2024 Created 11/08/2024 Added 11/07/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter. 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-41009 CVE - 2024-41009 https://errata.almalinux.org/8/ALSA-2024-8856.html https://errata.almalinux.org/8/ALSA-2024-8870.html https://errata.almalinux.org/9/ALSA-2024-10274.html

OS X update for Clock (CVE-2023-42943) Severity 5 CVSS (AV:L/AC:L/Au:S/C:C/I:N/A:N) Published 07/17/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in macOS Sonoma 14. An app may be able to read sensitive location information. Solution(s) apple-osx-upgrade-14 References https://attackerkb.com/topics/cve-2023-42943 CVE - 2023-42943 https://support.apple.com/kb/HT213940

Debian: CVE-2024-31143: xen -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/18/2024 Created 12/31/2024 Added 12/30/2024 Modified 12/30/2024 Description An optional feature of PCI MSI called "Multiple Message" allows a device to use multiple consecutive interrupt vectors.Unlike for MSI-X, the setting up of these consecutive vectors needs to happen all in one go.In this handling an error path could be taken in different situations, with or without a particular lock held.This error path wrongly releases the lock even when it is not currently held. Solution(s) debian-upgrade-xen References https://attackerkb.com/topics/cve-2024-31143 CVE - 2024-31143 DSA-5836-1

Huawei EulerOS: CVE-2024-40725: httpd security update Severity 5 CVSS (AV:N/AC:L/Au:N/C:P/I:N/A:N) Published 07/18/2024 Created 01/16/2025 Added 01/15/2025 Modified 01/30/2025 Description A partial fix for CVE-2024-39884 in the core of Apache HTTP Server 2.4.61 ignores some use of the legacy content-type based configuration of handlers. "AddType" and similar configuration, under some circumstances where files are requested indirectly, result in source code disclosure of local content. For example, PHP scripts may be served instead of interpreted. Users are recommended to upgrade to version 2.4.62, which fixes this issue. Solution(s) huawei-euleros-2_0_sp9-upgrade-httpd huawei-euleros-2_0_sp9-upgrade-httpd-filesystem huawei-euleros-2_0_sp9-upgrade-httpd-tools huawei-euleros-2_0_sp9-upgrade-mod_ssl References https://attackerkb.com/topics/cve-2024-40725 CVE - 2024-40725 EulerOS-SA-2025-1056

SUSE: CVE-2024-40647: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/18/2024 Created 07/24/2024 Added 07/24/2024 Modified 07/24/2024 Description sentry-sdk is the official Python SDK for Sentry.io. A bug in Sentry's Python SDK < 2.8.0 allows the environment variables to be passed to subprocesses despite the `env={}` setting. In Python's `subprocess` calls, all environment variables are passed to subprocesses by default. However, if you specifically do not want them to be passed to subprocesses, you may use `env` argument in `subprocess` calls. Due to the bug in Sentry SDK, with the Stdlib integration enabled (which is enabled by default), this expectation is not fulfilled, and all environment variables are being passed to subprocesses instead. The issue has been patched in pull request #3251 and is included in sentry-sdk==2.8.0. We strongly recommend upgrading to the latest SDK version. However, if it's not possible, and if passing environment variables to child processes poses a security risk for you, you can disable all default integrations. Solution(s) suse-upgrade-python3-sentry-sdk References https://attackerkb.com/topics/cve-2024-40647 CVE - 2024-40647

Oracle Linux: CVE-2024-41184: ELSA-2025-0743:keepalived security update (MODERATE) (Multiple Advisories) Severity 7 CVSS (AV:N/AC:L/Au:N/C:P/I:P/A:P) Published 07/18/2024 Created 01/31/2025 Added 01/29/2025 Modified 02/11/2025 Description In the vrrp_ipsets_handler handler (fglobal_parser.c) of keepalived through 2.3.1, an integer overflow can occur. NOTE: this CVE Record might not be worthwhile because an empty ipset name must be configured by the user. A flaw was found in the keepalived package. An integer overflow occurs when incorrect arguments are passed. As a result, reading from an undefined address takes place. Solution(s) oracle-linux-upgrade-keepalived References https://attackerkb.com/topics/cve-2024-41184 CVE - 2024-41184 ELSA-2025-0743 ELSA-2025-0917

Red Hat JBossEAP: Out-of-bounds Write (CVE-2023-7272) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 07/17/2024 Created 09/20/2024 Added 09/19/2024 Modified 12/20/2024 Description In Eclipse Parsson before 1.0.4 and 1.1.3, a document with a large depth of nested objects can allow an attacker to cause a Java stack overflow exception and denial of service. Eclipse Parsson allows processing (e.g. parse, generate, transform and query) JSON documents.. A flaw was found in Eclipse Parsson. A document containing a large depth of nested objects may allow an attacker to cause a Java stack overflow exception, potentially leading to a denial of service. Solution(s) red-hat-jboss-eap-upgrade-latest References https://attackerkb.com/topics/cve-2023-7272 CVE - 2023-7272 https://access.redhat.com/security/cve/CVE-2023-7272 https://bugzilla.redhat.com/show_bug.cgi?id=2298458 https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/12

Google Chrome Vulnerability: CVE-2024-6774 Use after free in Screen Capture Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 07/17/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description Use after free in Screen Capture in Google Chrome prior to 126.0.6478.182 allowed a remote attacker who convinced a user to engage in specific UI gestures to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) Solution(s) google-chrome-upgrade-latest References https://attackerkb.com/topics/cve-2024-6774 CVE - 2024-6774