ISHACK AI BOT

Amazon Linux AMI 2: CVE-2023-52612: Security patch for kernel (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/18/2024 Created 07/09/2024 Added 07/09/2024 Modified 07/09/2024 Description In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem. 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-4-14-343-259-562 amazon-linux-ami-2-upgrade-kernel-livepatch-5-10-209-198-812 amazon-linux-ami-2-upgrade-kernel-livepatch-5-15-148-97-158 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-52612 AL2/ALAS-2024-2549 AL2/ALASKERNEL-5.10-2024-048 AL2/ALASKERNEL-5.15-2024-036 AL2/ALASKERNEL-5.4-2024-059 CVE - 2023-52612

Amazon Linux AMI 2: CVE-2023-7250: Security patch for iperf3 (ALAS-2024-2579) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/18/2024 Created 06/26/2024 Added 06/26/2024 Modified 06/26/2024 Description A flaw was found in iperf, a utility for testing network performance using TCP, UDP, and SCTP. A malicious or malfunctioning client can send less than the expected amount of data to the iperf server, which can cause the server to hang indefinitely waiting for the remainder or until the connection gets closed. This will prevent other connections to the server, leading to a denial of service. Solution(s) amazon-linux-ami-2-upgrade-iperf3 amazon-linux-ami-2-upgrade-iperf3-debuginfo amazon-linux-ami-2-upgrade-iperf3-devel References https://attackerkb.com/topics/cve-2023-7250 AL2/ALAS-2024-2579 CVE - 2023-7250

Oracle Linux: CVE-2024-26635: ELSA-2024-12606: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 03/18/2024 Created 10/18/2024 Added 10/16/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: llc: Drop support for ETH_P_TR_802_2. syzbot reported an uninit-value bug below. [0] llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2 (0x0011), and syzbot abused the latter to trigger the bug. write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16) llc_conn_handler() initialises local variables {saddr,daddr}.mac based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes them to __llc_lookup(). However, the initialisation is done only when skb->protocol is htons(ETH_P_802_2), otherwise, __llc_lookup_established() and __llc_lookup_listener() will read garbage. The missing initialisation existed prior to commit 211ed865108e ("net: delete all instances of special processing for token ring"). It removed the part to kick out the token ring stuff but forgot to close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv(). Let's remove llc_tr_packet_type and complete the deprecation. [0]: BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Local variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-26635 CVE - 2024-26635 ELSA-2024-12606

VMware Photon OS: CVE-2023-7250 Severity 5 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:P) Published 03/18/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description A flaw was found in iperf, a utility for testing network performance using TCP, UDP, and SCTP. A malicious or malfunctioning client can send less than the expected amount of data to the iperf server, which can cause the server to hang indefinitely waiting for the remainder or until the connection gets closed. This will prevent other connections to the server, leading to a denial of service. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2023-7250 CVE - 2023-7250

Amazon Linux AMI 2: CVE-2024-23672: Security patch for tomcat (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/13/2024 Created 04/18/2024 Added 04/18/2024 Modified 04/19/2024 Description Denial of Service via incomplete cleanup vulnerability in Apache Tomcat. It was possible for WebSocket clients to keep WebSocket connections open leading to increased resource consumption.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98. Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue. Solution(s) amazon-linux-ami-2-upgrade-tomcat amazon-linux-ami-2-upgrade-tomcat-admin-webapps amazon-linux-ami-2-upgrade-tomcat-docs-webapp amazon-linux-ami-2-upgrade-tomcat-el-2-2-api amazon-linux-ami-2-upgrade-tomcat-el-3-0-api amazon-linux-ami-2-upgrade-tomcat-javadoc amazon-linux-ami-2-upgrade-tomcat-jsp-2-2-api amazon-linux-ami-2-upgrade-tomcat-jsp-2-3-api amazon-linux-ami-2-upgrade-tomcat-jsvc amazon-linux-ami-2-upgrade-tomcat-lib amazon-linux-ami-2-upgrade-tomcat-servlet-3-0-api amazon-linux-ami-2-upgrade-tomcat-servlet-3-1-api amazon-linux-ami-2-upgrade-tomcat-servlet-4-0-api amazon-linux-ami-2-upgrade-tomcat-webapps References https://attackerkb.com/topics/cve-2024-23672 AL2/ALAS-2024-2514 AL2/ALASTOMCAT8.5-2024-019 AL2/ALASTOMCAT9-2024-013 CVE - 2024-23672

Amazon Linux AMI: CVE-2024-24549: Security patch for tomcat8 (ALAS-2024-1941) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/13/2024 Created 06/26/2024 Added 06/24/2024 Modified 06/24/2024 Description Denial of Service due to improper input validation vulnerability for HTTP/2 requests in Apache Tomcat. When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98. Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue. Solution(s) amazon-linux-upgrade-tomcat8 References ALAS-2024-1941 CVE-2024-24549

OS X update for AppleMobileFileIntegrity (CVE-2024-23288) Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 03/13/2024 Created 03/14/2024 Added 03/13/2024 Modified 01/28/2025 Description This issue was addressed by removing the vulnerable code. This issue is fixed in tvOS 17.4, iOS 17.4 and iPadOS 17.4, macOS Sonoma 14.4, watchOS 10.4. An app may be able to elevate privileges. Solution(s) apple-osx-upgrade-14_4 References https://attackerkb.com/topics/cve-2024-23288 CVE - 2024-23288 https://support.apple.com/en-us/120895

Alma Linux: CVE-2024-26629: Moderate: kernel security update (ALSA-2024-6567) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/13/2024 Created 11/05/2024 Added 11/04/2024 Modified 11/04/2024 Description In the Linux kernel, the following vulnerability has been resolved: nfsd: fix RELEASE_LOCKOWNER The test on so_count in nfsd4_release_lockowner() is nonsense and harmful.Revert to using check_for_locks(), changing that to not sleep. First: harmful. As is documented in the kdoc comment for nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a return of NFS4ERR_LOCKS_HELD when in fact no locks are held.This is clearly a protocol violation and with the Linux NFS client it can cause incorrect behaviour. If RELEASE_LOCKOWNER is sent while some other thread is still processing a LOCK request which failed because, at the time that request was received, the given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error. The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so it knows that the error is impossible.It assumes the lock owner was in fact released so it feels free to use the same lock owner identifier in some later locking request. When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a lock_seqid of zero.However the server, which didn't release the lock owner, will expect a larger lock_seqid and so will respond with NFS4ERR_BAD_SEQID. So clearly it is harmful to allow a false positive, which testing so_count allows. The test is nonsense because ... well... it doesn't mean anything. so_count is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs locks owned by any of those states 3/ various transient counts such as for conflicting locks. When it is tested against '2' it is clear that one of these is the transient reference obtained by find_lockowner_str_locked().It is not clear what the other one is expected to be. In practice, the count is often 2 because there is precisely one state on so_stateids.If there were more, this would fail. In my testing I see two circumstances when RELEASE_LOCKOWNER is called. In one case, CLOSE is called before RELEASE_LOCKOWNER.That results in all the lock states being removed, and so the lockowner being discarded (it is removed when there are no more references which usually happens when the lock state is discarded).When nfsd4_release_lockowner() finds that the lock owner doesn't exist, it returns success. The other case shows an so_count of '2' and precisely one state listed in so_stateid.It appears that the Linux client uses a separate lock owner for each file resulting in one lock state per lock owner, so this test on '2' is safe.For another client it might not be safe. So this patch changes check_for_locks() to use the (newish) find_any_file_locked() so that it doesn't take a reference on the nfs4_file and so never calls nfsd_file_put(), and so never sleeps.With this check is it safe to restore the use of check_for_locks() rather than testing so_count against the mysterious '2'. 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-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-26629 CVE - 2024-26629 https://errata.almalinux.org/9/ALSA-2024-6567.html

SUSE: CVE-2024-26629: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/13/2024 Created 04/18/2024 Added 04/18/2024 Modified 05/06/2024 Description In the Linux kernel, the following vulnerability has been resolved: nfsd: fix RELEASE_LOCKOWNER The test on so_count in nfsd4_release_lockowner() is nonsense and harmful.Revert to using check_for_locks(), changing that to not sleep. First: harmful. As is documented in the kdoc comment for nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a return of NFS4ERR_LOCKS_HELD when in fact no locks are held.This is clearly a protocol violation and with the Linux NFS client it can cause incorrect behaviour. If RELEASE_LOCKOWNER is sent while some other thread is still processing a LOCK request which failed because, at the time that request was received, the given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error. The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so it knows that the error is impossible.It assumes the lock owner was in fact released so it feels free to use the same lock owner identifier in some later locking request. When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a lock_seqid of zero.However the server, which didn't release the lock owner, will expect a larger lock_seqid and so will respond with NFS4ERR_BAD_SEQID. So clearly it is harmful to allow a false positive, which testing so_count allows. The test is nonsense because ... well... it doesn't mean anything. so_count is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs locks owned by any of those states 3/ various transient counts such as for conflicting locks. When it is tested against '2' it is clear that one of these is the transient reference obtained by find_lockowner_str_locked().It is not clear what the other one is expected to be. In practice, the count is often 2 because there is precisely one state on so_stateids.If there were more, this would fail. In my testing I see two circumstances when RELEASE_LOCKOWNER is called. In one case, CLOSE is called before RELEASE_LOCKOWNER.That results in all the lock states being removed, and so the lockowner being discarded (it is removed when there are no more references which usually happens when the lock state is discarded).When nfsd4_release_lockowner() finds that the lock owner doesn't exist, it returns success. The other case shows an so_count of '2' and precisely one state listed in so_stateid.It appears that the Linux client uses a separate lock owner for each file resulting in one lock state per lock owner, so this test on '2' is safe.For another client it might not be safe. So this patch changes check_for_locks() to use the (newish) find_any_file_locked() so that it doesn't take a reference on the nfs4_file and so never calls nfsd_file_put(), and so never sleeps.With this check is it safe to restore the use of check_for_locks() rather than testing so_count against the mysterious '2'. 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-26629 CVE - 2024-26629

SUSE: CVE-2024-23672: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/13/2024 Created 04/12/2024 Added 04/12/2024 Modified 04/19/2024 Description Denial of Service via incomplete cleanup vulnerability in Apache Tomcat. It was possible for WebSocket clients to keep WebSocket connections open leading to increased resource consumption.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98. Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue. Solution(s) suse-upgrade-apache-commons-daemon suse-upgrade-apache-commons-daemon-javadoc suse-upgrade-apache-commons-daemon-jsvc suse-upgrade-apache-commons-dbcp suse-upgrade-apache-commons-dbcp-javadoc suse-upgrade-apache-commons-pool2 suse-upgrade-apache-commons-pool2-javadoc suse-upgrade-geronimo-annotation-1_0-api suse-upgrade-geronimo-commonj-1_1-apis suse-upgrade-geronimo-corba-1_0-apis suse-upgrade-geronimo-corba-2_3-apis suse-upgrade-geronimo-ejb-2_1-api suse-upgrade-geronimo-ejb-3_0-api suse-upgrade-geronimo-el-1_0-api suse-upgrade-geronimo-interceptor-3_0-api suse-upgrade-geronimo-j2ee-1_4-apis suse-upgrade-geronimo-j2ee-connector-1_5-api suse-upgrade-geronimo-j2ee-deployment-1_1-api suse-upgrade-geronimo-j2ee-management-1_0-api suse-upgrade-geronimo-j2ee-management-1_1-api suse-upgrade-geronimo-jacc-1_0-api suse-upgrade-geronimo-jacc-1_1-api suse-upgrade-geronimo-jaf-1_0_2-api suse-upgrade-geronimo-jaf-1_1-api suse-upgrade-geronimo-javaee-deployment-1_1-api suse-upgrade-geronimo-javamail-1_3_1-api suse-upgrade-geronimo-javamail-1_4-api suse-upgrade-geronimo-jaxr-1_0-api suse-upgrade-geronimo-jaxrpc-1_1-api suse-upgrade-geronimo-jms-1_1-api suse-upgrade-geronimo-jpa-3_0-api suse-upgrade-geronimo-jsp-2_0-api suse-upgrade-geronimo-jsp-2_1-api suse-upgrade-geronimo-jta-1_0_1b-api suse-upgrade-geronimo-jta-1_1-api suse-upgrade-geronimo-qname-1_1-api suse-upgrade-geronimo-saaj-1_1-api suse-upgrade-geronimo-servlet-2_4-api suse-upgrade-geronimo-servlet-2_5-api suse-upgrade-geronimo-stax-1_0-api suse-upgrade-geronimo-ws-metadata-2_0-api suse-upgrade-jakarta-taglibs-standard suse-upgrade-jakarta-taglibs-standard-javadoc suse-upgrade-tomcat suse-upgrade-tomcat-admin-webapps suse-upgrade-tomcat-docs-webapp suse-upgrade-tomcat-el-3_0-api suse-upgrade-tomcat-embed suse-upgrade-tomcat-javadoc suse-upgrade-tomcat-jsp-2_3-api suse-upgrade-tomcat-jsvc suse-upgrade-tomcat-lib suse-upgrade-tomcat-servlet-4_0-api suse-upgrade-tomcat-webapps suse-upgrade-tomcat10 suse-upgrade-tomcat10-admin-webapps suse-upgrade-tomcat10-docs-webapp suse-upgrade-tomcat10-el-5_0-api suse-upgrade-tomcat10-embed suse-upgrade-tomcat10-jsp-3_1-api suse-upgrade-tomcat10-jsvc suse-upgrade-tomcat10-lib suse-upgrade-tomcat10-servlet-6_0-api suse-upgrade-tomcat10-webapps References https://attackerkb.com/topics/cve-2024-23672 CVE - 2024-23672

SUSE: CVE-2024-2400: SUSE Linux Security Advisory Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 03/13/2024 Created 03/20/2024 Added 03/19/2024 Modified 01/28/2025 Description Use after free in Performance Manager in Google Chrome prior to 122.0.6261.128 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) Solution(s) suse-upgrade-chromedriver suse-upgrade-chromium suse-upgrade-clang17 suse-upgrade-clang17-devel suse-upgrade-clang17-doc suse-upgrade-libclang-cpp17 suse-upgrade-libclang-cpp17-32bit suse-upgrade-libclang-cpp17-64bit suse-upgrade-liblldb17 suse-upgrade-libllvm17 suse-upgrade-libllvm17-32bit suse-upgrade-libllvm17-64bit suse-upgrade-liblto17 suse-upgrade-libomp17-devel suse-upgrade-lld17 suse-upgrade-lldb17 suse-upgrade-lldb17-devel suse-upgrade-llvm17 suse-upgrade-llvm17-devel suse-upgrade-llvm17-doc suse-upgrade-llvm17-gold suse-upgrade-llvm17-libc-1 suse-upgrade-llvm17-libc-abi-devel suse-upgrade-llvm17-libc-abi1 suse-upgrade-llvm17-libc-devel suse-upgrade-llvm17-libclang13 suse-upgrade-llvm17-opt-viewer suse-upgrade-llvm17-polly suse-upgrade-llvm17-polly-devel suse-upgrade-llvm17-vim-plugins suse-upgrade-opera suse-upgrade-python3-clang17 suse-upgrade-python3-lldb17 References https://attackerkb.com/topics/cve-2024-2400 CVE - 2024-2400

Huawei EulerOS: CVE-2023-39804: tar security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/13/2024 Created 03/14/2024 Added 03/13/2024 Modified 03/28/2024 Description In GNU tar before 1.35, mishandled extension attributes in a PAX archive can lead to an application crash in xheader.c. Solution(s) huawei-euleros-2_0_sp10-upgrade-tar References https://attackerkb.com/topics/cve-2023-39804 CVE - 2023-39804 EulerOS-SA-2024-1350

OS X update for Messages (CVE-2024-23287) Severity 5 CVSS (AV:L/AC:L/Au:S/C:C/I:N/A:N) Published 03/13/2024 Created 03/14/2024 Added 03/13/2024 Modified 01/28/2025 Description A privacy issue was addressed with improved handling of temporary files. This issue is fixed in macOS Sonoma 14.4, iOS 17.4 and iPadOS 17.4, watchOS 10.4. An app may be able to access user-sensitive data. Solution(s) apple-osx-upgrade-14_4 References https://attackerkb.com/topics/cve-2024-23287 CVE - 2024-23287 https://support.apple.com/en-us/120895

OS X update for Music (CVE-2024-23285) Severity 5 CVSS (AV:L/AC:M/Au:N/C:N/I:C/A:N) Published 03/13/2024 Created 03/14/2024 Added 03/13/2024 Modified 01/28/2025 Description This issue was addressed with improved handling of symlinks. This issue is fixed in macOS Sonoma 14.4. An app may be able to create symlinks to protected regions of the disk. Solution(s) apple-osx-upgrade-14_4 References https://attackerkb.com/topics/cve-2024-23285 CVE - 2024-23285 https://support.apple.com/en-us/120895

Rocky Linux: CVE-2024-26629: kernel (RLSA-2024-6567) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/13/2024 Created 09/18/2024 Added 09/17/2024 Modified 11/18/2024 Description In the Linux kernel, the following vulnerability has been resolved: nfsd: fix RELEASE_LOCKOWNER The test on so_count in nfsd4_release_lockowner() is nonsense and harmful.Revert to using check_for_locks(), changing that to not sleep. First: harmful. As is documented in the kdoc comment for nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a return of NFS4ERR_LOCKS_HELD when in fact no locks are held.This is clearly a protocol violation and with the Linux NFS client it can cause incorrect behaviour. If RELEASE_LOCKOWNER is sent while some other thread is still processing a LOCK request which failed because, at the time that request was received, the given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error. The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so it knows that the error is impossible.It assumes the lock owner was in fact released so it feels free to use the same lock owner identifier in some later locking request. When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a lock_seqid of zero.However the server, which didn't release the lock owner, will expect a larger lock_seqid and so will respond with NFS4ERR_BAD_SEQID. So clearly it is harmful to allow a false positive, which testing so_count allows. The test is nonsense because ... well... it doesn't mean anything. so_count is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs locks owned by any of those states 3/ various transient counts such as for conflicting locks. When it is tested against '2' it is clear that one of these is the transient reference obtained by find_lockowner_str_locked().It is not clear what the other one is expected to be. In practice, the count is often 2 because there is precisely one state on so_stateids.If there were more, this would fail. In my testing I see two circumstances when RELEASE_LOCKOWNER is called. In one case, CLOSE is called before RELEASE_LOCKOWNER.That results in all the lock states being removed, and so the lockowner being discarded (it is removed when there are no more references which usually happens when the lock state is discarded).When nfsd4_release_lockowner() finds that the lock owner doesn't exist, it returns success. The other case shows an so_count of '2' and precisely one state listed in so_stateid.It appears that the Linux client uses a separate lock owner for each file resulting in one lock state per lock owner, so this test on '2' is safe.For another client it might not be safe. So this patch changes check_for_locks() to use the (newish) find_any_file_locked() so that it doesn't take a reference on the nfs4_file and so never calls nfsd_file_put(), and so never sleeps.With this check is it safe to restore the use of check_for_locks() rather than testing so_count against the mysterious '2'. 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-devel-matched rocky-upgrade-kernel-debug-modules rocky-upgrade-kernel-debug-modules-core rocky-upgrade-kernel-debug-modules-extra rocky-upgrade-kernel-debug-uki-virt rocky-upgrade-kernel-debuginfo rocky-upgrade-kernel-devel rocky-upgrade-kernel-devel-matched rocky-upgrade-kernel-headers rocky-upgrade-kernel-modules rocky-upgrade-kernel-modules-core 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-core rocky-upgrade-kernel-rt-debug-modules-extra rocky-upgrade-kernel-rt-debuginfo rocky-upgrade-kernel-rt-devel rocky-upgrade-kernel-rt-kvm rocky-upgrade-kernel-rt-modules rocky-upgrade-kernel-rt-modules-core 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-kernel-uki-virt rocky-upgrade-kernel-zfcpdump rocky-upgrade-kernel-zfcpdump-core rocky-upgrade-kernel-zfcpdump-debuginfo rocky-upgrade-kernel-zfcpdump-devel rocky-upgrade-kernel-zfcpdump-devel-matched rocky-upgrade-kernel-zfcpdump-modules rocky-upgrade-kernel-zfcpdump-modules-core rocky-upgrade-kernel-zfcpdump-modules-extra rocky-upgrade-libperf rocky-upgrade-libperf-debuginfo rocky-upgrade-perf rocky-upgrade-perf-debuginfo rocky-upgrade-python3-perf rocky-upgrade-python3-perf-debuginfo rocky-upgrade-rtla rocky-upgrade-rv References https://attackerkb.com/topics/cve-2024-26629 CVE - 2024-26629 https://errata.rockylinux.org/RLSA-2024:6567

SUSE: CVE-2024-24549: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/13/2024 Created 04/12/2024 Added 04/12/2024 Modified 04/19/2024 Description Denial of Service due to improper input validation vulnerability for HTTP/2 requests in Apache Tomcat. When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98. Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue. Solution(s) suse-upgrade-apache-commons-daemon suse-upgrade-apache-commons-daemon-javadoc suse-upgrade-apache-commons-daemon-jsvc suse-upgrade-apache-commons-dbcp suse-upgrade-apache-commons-dbcp-javadoc suse-upgrade-apache-commons-pool2 suse-upgrade-apache-commons-pool2-javadoc suse-upgrade-geronimo-annotation-1_0-api suse-upgrade-geronimo-commonj-1_1-apis suse-upgrade-geronimo-corba-1_0-apis suse-upgrade-geronimo-corba-2_3-apis suse-upgrade-geronimo-ejb-2_1-api suse-upgrade-geronimo-ejb-3_0-api suse-upgrade-geronimo-el-1_0-api suse-upgrade-geronimo-interceptor-3_0-api suse-upgrade-geronimo-j2ee-1_4-apis suse-upgrade-geronimo-j2ee-connector-1_5-api suse-upgrade-geronimo-j2ee-deployment-1_1-api suse-upgrade-geronimo-j2ee-management-1_0-api suse-upgrade-geronimo-j2ee-management-1_1-api suse-upgrade-geronimo-jacc-1_0-api suse-upgrade-geronimo-jacc-1_1-api suse-upgrade-geronimo-jaf-1_0_2-api suse-upgrade-geronimo-jaf-1_1-api suse-upgrade-geronimo-javaee-deployment-1_1-api suse-upgrade-geronimo-javamail-1_3_1-api suse-upgrade-geronimo-javamail-1_4-api suse-upgrade-geronimo-jaxr-1_0-api suse-upgrade-geronimo-jaxrpc-1_1-api suse-upgrade-geronimo-jms-1_1-api suse-upgrade-geronimo-jpa-3_0-api suse-upgrade-geronimo-jsp-2_0-api suse-upgrade-geronimo-jsp-2_1-api suse-upgrade-geronimo-jta-1_0_1b-api suse-upgrade-geronimo-jta-1_1-api suse-upgrade-geronimo-qname-1_1-api suse-upgrade-geronimo-saaj-1_1-api suse-upgrade-geronimo-servlet-2_4-api suse-upgrade-geronimo-servlet-2_5-api suse-upgrade-geronimo-stax-1_0-api suse-upgrade-geronimo-ws-metadata-2_0-api suse-upgrade-jakarta-taglibs-standard suse-upgrade-jakarta-taglibs-standard-javadoc suse-upgrade-tomcat suse-upgrade-tomcat-admin-webapps suse-upgrade-tomcat-docs-webapp suse-upgrade-tomcat-el-3_0-api suse-upgrade-tomcat-embed suse-upgrade-tomcat-javadoc suse-upgrade-tomcat-jsp-2_3-api suse-upgrade-tomcat-jsvc suse-upgrade-tomcat-lib suse-upgrade-tomcat-servlet-4_0-api suse-upgrade-tomcat-webapps suse-upgrade-tomcat10 suse-upgrade-tomcat10-admin-webapps suse-upgrade-tomcat10-docs-webapp suse-upgrade-tomcat10-el-5_0-api suse-upgrade-tomcat10-embed suse-upgrade-tomcat10-jsp-3_1-api suse-upgrade-tomcat10-jsvc suse-upgrade-tomcat10-lib suse-upgrade-tomcat10-servlet-6_0-api suse-upgrade-tomcat10-webapps References https://attackerkb.com/topics/cve-2024-24549 CVE - 2024-24549

Microsoft Edge Chromium: CVE-2024-2400 Use after free in Performance Manager Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 03/13/2024 Created 03/16/2024 Added 03/15/2024 Modified 01/28/2025 Description Use after free in Performance Manager in Google Chrome prior to 122.0.6261.128 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) Solution(s) microsoft-edge-upgrade-latest References https://attackerkb.com/topics/cve-2024-2400 CVE - 2024-2400 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-2400

Google Chrome Vulnerability: CVE-2024-2400 Use after free in Performance Manager Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 03/13/2024 Created 03/14/2024 Added 03/13/2024 Modified 01/28/2025 Description Use after free in Performance Manager in Google Chrome prior to 122.0.6261.128 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-2400 CVE - 2024-2400

Cisco End-of-Security-Support Products Severity 10 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 03/13/2024 Created 03/20/2024 Added 03/13/2024 Modified 02/01/2025 Description The security support for this product has ended. Cisco Engineering will no longer release a planned maintenance release or scheduled software remedy for a security vulnerability issue.Visit Cisco End-of-Life Policy Solution(s) cisco-eoss-products

OS X update for TV App (CVE-2024-23260) Severity 5 CVSS (AV:L/AC:M/Au:N/C:C/I:N/A:N) Published 03/13/2024 Created 03/14/2024 Added 03/13/2024 Modified 01/28/2025 Description This issue was addressed by removing additional entitlements. This issue is fixed in macOS Sonoma 14.4. An app may be able to access user-sensitive data. Solution(s) apple-osx-upgrade-14_4 References https://attackerkb.com/topics/cve-2024-23260 CVE - 2024-23260 https://support.apple.com/en-us/120895

OS X update for Synapse (CVE-2024-23242) Severity 2 CVSS (AV:L/AC:M/Au:N/C:P/I:N/A:N) Published 03/13/2024 Created 03/14/2024 Added 03/13/2024 Modified 01/28/2025 Description A privacy issue was addressed by not logging contents of text fields. This issue is fixed in macOS Sonoma 14.4, iOS 17.4 and iPadOS 17.4. An app may be able to view Mail data. Solution(s) apple-osx-upgrade-14_4 References https://attackerkb.com/topics/cve-2024-23242 CVE - 2024-23242 https://support.apple.com/en-us/120895

OS X update for Siri (CVE-2024-23289) Severity 2 CVSS (AV:L/AC:L/Au:S/C:P/I:N/A:N) Published 03/13/2024 Created 03/14/2024 Added 03/13/2024 Modified 01/28/2025 Description A lock screen issue was addressed with improved state management. This issue is fixed in iOS 16.7.6 and iPadOS 16.7.6, iOS 17.4 and iPadOS 17.4, macOS Sonoma 14.4, watchOS 10.4. A person with physical access to a device may be able to use Siri to access private calendar information. Solution(s) apple-osx-upgrade-14_4 References https://attackerkb.com/topics/cve-2024-23289 CVE - 2024-23289 https://support.apple.com/en-us/120895

Amazon Linux AMI 2: Security patch for aws-nitro-enclaves-cli (ALASNITRO-ENCLAVES-2024-039) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/13/2024 Created 03/20/2024 Added 03/19/2024 Modified 03/19/2024 Description RUSTSEC-2024-0006 NOTE: https://rustsec.org/advisories/RUSTSEC-2024-0006.html NOTE: https://github.com/comex/rust-shlex/security/advisories/GHSA-r7qv-8r2h-pg27 Solution(s) amazon-linux-ami-2-upgrade-aws-nitro-enclaves-cli amazon-linux-ami-2-upgrade-aws-nitro-enclaves-cli-debuginfo amazon-linux-ami-2-upgrade-aws-nitro-enclaves-cli-devel amazon-linux-ami-2-upgrade-aws-nitro-enclaves-cli-integration-tests References AL2/ALASNITRO-ENCLAVES-2024-039

Amazon Linux AMI 2: Security patch for rust (ALAS-2024-2504) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/13/2024 Created 03/20/2024 Added 03/19/2024 Modified 03/19/2024 Description RUSTSEC-2024-0006 NOTE: https://rustsec.org/advisories/RUSTSEC-2024-0006.html NOTE: https://github.com/comex/rust-shlex/security/advisories/GHSA-r7qv-8r2h-pg27 Solution(s) amazon-linux-ami-2-upgrade-cargo amazon-linux-ami-2-upgrade-clippy amazon-linux-ami-2-upgrade-rust amazon-linux-ami-2-upgrade-rust-analysis amazon-linux-ami-2-upgrade-rust-analyzer amazon-linux-ami-2-upgrade-rust-debugger-common amazon-linux-ami-2-upgrade-rust-debuginfo amazon-linux-ami-2-upgrade-rust-doc amazon-linux-ami-2-upgrade-rust-gdb amazon-linux-ami-2-upgrade-rust-src amazon-linux-ami-2-upgrade-rust-std-static amazon-linux-ami-2-upgrade-rust-toolset amazon-linux-ami-2-upgrade-rustfmt References AL2/ALAS-2024-2504

Red Hat: CVE-2023-39368: kernel: Possible Denial of Service on Intel(R) Processors (Multiple Advisories) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 03/14/2024 Created 11/14/2024 Added 11/13/2024 Modified 11/13/2024 Description Protection mechanism failure of bus lock regulator for some Intel(R) Processors may allow an unauthenticated user to potentially enable denial of service via network access. Solution(s) redhat-upgrade-microcode_ctl References CVE-2023-39368 RHSA-2024:9401