ISHACK AI BOT

Alma Linux: CVE-2024-36016: Important: kernel security update (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 08/13/2024 Added 08/12/2024 Modified 11/04/2024 Description In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size. 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-kvm 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-kvm 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-36016 CVE - 2024-36016 https://errata.almalinux.org/8/ALSA-2024-5101.html https://errata.almalinux.org/8/ALSA-2024-5102.html https://errata.almalinux.org/9/ALSA-2024-6997.html

Ubuntu: (CVE-2023-52881): linux vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: tcp: do not accept ACK of bytes we never sent This patch is based on a detailed report and ideas from Yepeng Pan and Christian Rossow. ACK seq validation is currently following RFC 5961 5.2 guidelines: The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT).All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back.It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored.If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return".The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable.This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through. This can be refined for new (and possibly spoofed) flows, by not accepting ACK for bytes that were never sent. This greatly improves TCP security at a little cost. I added a Fixes: tag to make sure this patch will reach stable trees, even if the 'blamed' patch was adhering to the RFC. tp->bytes_acked was added in linux-4.2 Following packetdrill test (courtesy of Yepeng Pan) shows the issue at hand: 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1024) = 0 // ---------------- Handshake ------------------- // // when window scale is set to 14 the window size can be extended to // 65535 * (2^14) = 1073725440. Linux would accept an ACK packet // with ack number in (Server_ISN+1-1073725440. Server_ISN+1) // ,though this ack number acknowledges some data never // sent by the server. +0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14> +0 > S. 0:0(0) ack 1 <...> +0 < . 1:1(0) ack 1 win 65535 +0 accept(3, ..., ...) = 4 // For the established connection, we send an ACK packet, // the ack packet uses ack number 1 - 1073725300 + 2^32, // where 2^32 is used to wrap around. // Note: we used 1073725300 instead of 1073725440 to avoid possible // edge cases. // 1 - 1073725300 + 2^32 = 3221241997 // Oops, old kernels happily accept this packet. +0 < . 1:1001(1000) ack 3221241997 win 65535 // After the kernel fix the following will be replaced by a challenge ACK, // and prior malicious frame would be dropped. +0 > . 1:1(0) ack 1001 Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-15 ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-5-15 ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-azure-fde ubuntu-upgrade-linux-azure-fde-5-15 ubuntu-upgrade-linux-azure-fips ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-5-15 ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gke ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-gkeop-5-15 ubuntu-upgrade-linux-hwe-5-15 ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-ibm ubuntu-upgrade-linux-ibm-5-15 ubuntu-upgrade-linux-ibm-5-4 ubuntu-upgrade-linux-intel-iot-realtime ubuntu-upgrade-linux-intel-iotg ubuntu-upgrade-linux-intel-iotg-5-15 ubuntu-upgrade-linux-iot ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-lowlatency ubuntu-upgrade-linux-lowlatency-hwe-5-15 ubuntu-upgrade-linux-nvidia ubuntu-upgrade-linux-nvidia-6-5 ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-15 ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 ubuntu-upgrade-linux-realtime ubuntu-upgrade-linux-riscv-5-15 ubuntu-upgrade-linux-xilinx-zynqmp References https://attackerkb.com/topics/cve-2023-52881 CVE - 2023-52881 https://git.kernel.org/linus/3d501dd326fb1c73f1b8206d4c6e1d7b15c07e27 https://git.kernel.org/stable/c/008b807fe487e0b15a3a6c39add4eb477f73e440 https://git.kernel.org/stable/c/0d4e0afdd6658cd21dd5be61880411a2553fd1fc https://git.kernel.org/stable/c/2087d53a66e97a5eb5d1bf558d5bef9e5f891757 https://git.kernel.org/stable/c/3d501dd326fb1c73f1b8206d4c6e1d7b15c07e27 https://git.kernel.org/stable/c/458f07ffeccd17f99942311e09ef574ddf4a414a https://git.kernel.org/stable/c/69eae75ca5255e876628ac5cee9eaab31f644b57 https://git.kernel.org/stable/c/7ffff0cc929fdfc62a74b384c4903d6496c910f0 https://git.kernel.org/stable/c/b17a886ed29f3b70b78ccf632dad03e0c69e3c1a https://www.cve.org/CVERecord?id=CVE-2023-52881 View more

VMware Photon OS: CVE-2024-31079 Severity 4 CVSS (AV:N/AC:H/Au:N/C:N/I:P/A:P) Published 05/29/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description When NGINX Plus or NGINX OSS are configured to use the HTTP/3 QUIC module, undisclosed HTTP/3 requests can cause NGINX worker processes to terminate or cause other potential impact. This attack requires that a request be specifically timed during the connection draining process, which the attacker has no visibility and limited influence over. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-31079 CVE - 2024-31079

Huawei EulerOS: CVE-2023-52340: kernel security update Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 05/29/2024 Created 06/01/2024 Added 05/31/2024 Modified 01/28/2025 Description The IPv6 implementation in the Linux kernel before 6.3 has a net/ipv6/route.c max_size threshold that can be consumed easily, e.g., leading to a denial of service (network is unreachable errors) when IPv6 packets are sent in a loop via a raw socket. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2023-52340 CVE - 2023-52340 EulerOS-SA-2024-1764

Debian: CVE-2024-36014: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/29/2024 Created 06/28/2024 Added 06/27/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/arm/malidp: fix a possible null pointer dereference In malidp_mw_connector_reset, new memory is allocated with kzalloc, but no check is performed. In order to prevent null pointer dereferencing, ensure that mw_state is checked before calling __drm_atomic_helper_connector_reset. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-36014 CVE - 2024-36014 DLA-3840-1

Oracle Linux: CVE-2024-36015: ELSA-2024-12581: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/29/2024 Created 08/20/2024 Added 08/16/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: ppdev: Add an error check in register_device In register_device, the return value of ida_simple_get is unchecked, in witch ida_simple_get will use an invalid index value. To address this issue, index should be checked after ida_simple_get. When the index value is abnormal, a warning message should be printed, the port should be dropped, and the value should be recorded. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-36015 CVE - 2024-36015 ELSA-2024-12581 ELSA-2024-12584 ELSA-2024-12585 ELSA-2024-12611

Huawei EulerOS: CVE-2024-36015: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: ppdev: Add an error check in register_device In register_device, the return value of ida_simple_get is unchecked, in witch ida_simple_get will use an invalid index value. To address this issue, index should be checked after ida_simple_get. When the index value is abnormal, a warning message should be printed, the port should be dropped, and the value should be recorded. 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-36015 CVE - 2024-36015 EulerOS-SA-2024-2441

Huawei EulerOS: CVE-2023-52881: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 01/23/2025 Added 01/21/2025 Modified 01/21/2025 Description In the Linux kernel, the following vulnerability has been resolved: tcp: do not accept ACK of bytes we never sent This patch is based on a detailed report and ideas from Yepeng Pan and Christian Rossow. ACK seq validation is currently following RFC 5961 5.2 guidelines: The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT).All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back.It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored.If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return".The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable.This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through. This can be refined for new (and possibly spoofed) flows, by not accepting ACK for bytes that were never sent. This greatly improves TCP security at a little cost. I added a Fixes: tag to make sure this patch will reach stable trees, even if the 'blamed' patch was adhering to the RFC. tp->bytes_acked was added in linux-4.2 Following packetdrill test (courtesy of Yepeng Pan) shows the issue at hand: 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1024) = 0 // ---------------- Handshake ------------------- // // when window scale is set to 14 the window size can be extended to // 65535 * (2^14) = 1073725440. Linux would accept an ACK packet // with ack number in (Server_ISN+1-1073725440. Server_ISN+1) // ,though this ack number acknowledges some data never // sent by the server. +0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14> +0 > S. 0:0(0) ack 1 <...> +0 < . 1:1(0) ack 1 win 65535 +0 accept(3, ..., ...) = 4 // For the established connection, we send an ACK packet, // the ack packet uses ack number 1 - 1073725300 + 2^32, // where 2^32 is used to wrap around. // Note: we used 1073725300 instead of 1073725440 to avoid possible // edge cases. // 1 - 1073725300 + 2^32 = 3221241997 // Oops, old kernels happily accept this packet. +0 < . 1:1001(1000) ack 3221241997 win 65535 // After the kernel fix the following will be replaced by a challenge ACK, // and prior malicious frame would be dropped. +0 > . 1:1(0) ack 1001 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-2023-52881 CVE - 2023-52881 EulerOS-SA-2025-1123

Huawei EulerOS: CVE-2024-35221: ruby security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description Rubygems.org is the Ruby community's gem hosting service. A Gem publisher can cause a Remote DoS when publishing a Gem. This is due to how Ruby reads the Manifest of Gem files when using Gem::Specification.from_yaml. from_yaml makes use of SafeYAML.load which allows YAML aliases inside the YAML-based metadata of a gem. YAML aliases allow for Denial of Service attacks with so-called `YAML-bombs` (comparable to Billion laughs attacks). This was patched. There is is no action required by users. This issue is also tracked as GHSL-2024-001 and was discovered by the GitHub security lab. Solution(s) huawei-euleros-2_0_sp10-upgrade-ruby huawei-euleros-2_0_sp10-upgrade-ruby-help huawei-euleros-2_0_sp10-upgrade-ruby-irb References https://attackerkb.com/topics/cve-2024-35221 CVE - 2024-35221 EulerOS-SA-2024-2452

Ubuntu: USN-6796-1 (CVE-2024-29040): TPM2 Software Stack vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 06/07/2024 Added 06/06/2024 Modified 10/23/2024 Description This repository hosts source code implementing the Trusted Computing Group's (TCG) TPM2 Software Stack (TSS). The JSON Quote Info returned by Fapi_Quote has to be deserialized by Fapi_VerifyQuote to the TPM Structure `TPMS_ATTEST`. For the field `TPM2_GENERATED magic` of this structure any number can be used in the JSON structure. The verifier can receive a state which does not represent the actual, possibly malicious state of the device under test. The malicious device might get access to data it shouldn't, or can use services it shouldn't be able to. This issue has been patched in version 4.1.0. Solution(s) ubuntu-upgrade-libtss2-esys-3-0-2-0 ubuntu-upgrade-libtss2-esys-3-0-2-0t64 ubuntu-upgrade-libtss2-esys0 ubuntu-upgrade-libtss2-fapi1 ubuntu-upgrade-libtss2-fapi1t64 ubuntu-upgrade-libtss2-mu-4-0-1-0t64 ubuntu-upgrade-libtss2-mu0 ubuntu-upgrade-libtss2-policy0 ubuntu-upgrade-libtss2-policy0t64 ubuntu-upgrade-libtss2-rc0 ubuntu-upgrade-libtss2-rc0t64 ubuntu-upgrade-libtss2-sys1 ubuntu-upgrade-libtss2-sys1t64 ubuntu-upgrade-libtss2-tcti-cmd0 ubuntu-upgrade-libtss2-tcti-cmd0t64 ubuntu-upgrade-libtss2-tcti-device0 ubuntu-upgrade-libtss2-tcti-device0t64 ubuntu-upgrade-libtss2-tcti-libtpms0 ubuntu-upgrade-libtss2-tcti-libtpms0t64 ubuntu-upgrade-libtss2-tcti-mssim0 ubuntu-upgrade-libtss2-tcti-mssim0t64 ubuntu-upgrade-libtss2-tcti-pcap0 ubuntu-upgrade-libtss2-tcti-pcap0t64 ubuntu-upgrade-libtss2-tcti-spi-helper0 ubuntu-upgrade-libtss2-tcti-spi-helper0t64 ubuntu-upgrade-libtss2-tcti-swtpm0 ubuntu-upgrade-libtss2-tcti-swtpm0t64 ubuntu-upgrade-libtss2-tctildr0 ubuntu-upgrade-libtss2-tctildr0t64 References https://attackerkb.com/topics/cve-2024-29040 CVE - 2024-29040 USN-6796-1

Ubuntu: (Multiple Advisories) (CVE-2024-36016): Linux kernel vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 07/31/2024 Added 07/31/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size. Solution(s) ubuntu-upgrade-linux-image-4-15-0-1133-oracle ubuntu-upgrade-linux-image-4-15-0-1154-kvm ubuntu-upgrade-linux-image-4-15-0-1164-gcp ubuntu-upgrade-linux-image-4-15-0-1170-aws ubuntu-upgrade-linux-image-4-15-0-1179-azure ubuntu-upgrade-linux-image-4-15-0-227-generic ubuntu-upgrade-linux-image-4-15-0-227-lowlatency ubuntu-upgrade-linux-image-4-4-0-1134-aws ubuntu-upgrade-linux-image-4-4-0-1135-kvm ubuntu-upgrade-linux-image-4-4-0-1172-aws ubuntu-upgrade-linux-image-4-4-0-257-generic ubuntu-upgrade-linux-image-4-4-0-257-lowlatency ubuntu-upgrade-linux-image-5-15-0-1035-xilinx-zynqmp ubuntu-upgrade-linux-image-5-15-0-1049-gkeop ubuntu-upgrade-linux-image-5-15-0-1059-ibm ubuntu-upgrade-linux-image-5-15-0-1059-raspi ubuntu-upgrade-linux-image-5-15-0-1061-intel-iotg ubuntu-upgrade-linux-image-5-15-0-1061-nvidia ubuntu-upgrade-linux-image-5-15-0-1061-nvidia-lowlatency ubuntu-upgrade-linux-image-5-15-0-1063-gke ubuntu-upgrade-linux-image-5-15-0-1063-kvm ubuntu-upgrade-linux-image-5-15-0-1064-oracle ubuntu-upgrade-linux-image-5-15-0-1065-gcp ubuntu-upgrade-linux-image-5-15-0-1065-oracle ubuntu-upgrade-linux-image-5-15-0-1066-aws ubuntu-upgrade-linux-image-5-15-0-1070-azure ubuntu-upgrade-linux-image-5-15-0-1070-azure-fde ubuntu-upgrade-linux-image-5-15-0-117-generic ubuntu-upgrade-linux-image-5-15-0-117-generic-64k ubuntu-upgrade-linux-image-5-15-0-117-generic-lpae ubuntu-upgrade-linux-image-5-15-0-117-lowlatency ubuntu-upgrade-linux-image-5-15-0-117-lowlatency-64k ubuntu-upgrade-linux-image-5-4-0-1041-iot ubuntu-upgrade-linux-image-5-4-0-1048-xilinx-zynqmp ubuntu-upgrade-linux-image-5-4-0-1076-ibm ubuntu-upgrade-linux-image-5-4-0-1089-bluefield ubuntu-upgrade-linux-image-5-4-0-1096-gkeop ubuntu-upgrade-linux-image-5-4-0-1113-raspi ubuntu-upgrade-linux-image-5-4-0-1114-raspi ubuntu-upgrade-linux-image-5-4-0-1117-kvm ubuntu-upgrade-linux-image-5-4-0-1129-aws ubuntu-upgrade-linux-image-5-4-0-1129-oracle ubuntu-upgrade-linux-image-5-4-0-1133-gcp ubuntu-upgrade-linux-image-5-4-0-1134-azure ubuntu-upgrade-linux-image-5-4-0-190-generic ubuntu-upgrade-linux-image-5-4-0-190-generic-lpae ubuntu-upgrade-linux-image-5-4-0-190-lowlatency ubuntu-upgrade-linux-image-6-8-0-1007-gke ubuntu-upgrade-linux-image-6-8-0-1008-raspi ubuntu-upgrade-linux-image-6-8-0-1009-ibm ubuntu-upgrade-linux-image-6-8-0-1009-oem ubuntu-upgrade-linux-image-6-8-0-1010-nvidia ubuntu-upgrade-linux-image-6-8-0-1010-nvidia-64k ubuntu-upgrade-linux-image-6-8-0-1010-oracle ubuntu-upgrade-linux-image-6-8-0-1010-oracle-64k ubuntu-upgrade-linux-image-6-8-0-1011-gcp ubuntu-upgrade-linux-image-6-8-0-1011-nvidia-lowlatency ubuntu-upgrade-linux-image-6-8-0-1011-nvidia-lowlatency-64k ubuntu-upgrade-linux-image-6-8-0-1012-aws ubuntu-upgrade-linux-image-6-8-0-1012-azure ubuntu-upgrade-linux-image-6-8-0-1012-azure-fde ubuntu-upgrade-linux-image-6-8-0-39-generic ubuntu-upgrade-linux-image-6-8-0-39-generic-64k ubuntu-upgrade-linux-image-6-8-0-39-lowlatency ubuntu-upgrade-linux-image-6-8-0-39-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-aws-hwe ubuntu-upgrade-linux-image-aws-lts-18-04 ubuntu-upgrade-linux-image-aws-lts-20-04 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-18-04 ubuntu-upgrade-linux-image-azure-lts-20-04 ubuntu-upgrade-linux-image-azure-lts-22-04 ubuntu-upgrade-linux-image-bluefield ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-gcp-lts-18-04 ubuntu-upgrade-linux-image-gcp-lts-20-04 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-24-04 ubuntu-upgrade-linux-image-generic-hwe-16-04 ubuntu-upgrade-linux-image-generic-hwe-18-04 ubuntu-upgrade-linux-image-generic-hwe-20-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-generic-lts-xenial 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-5-4 ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-classic ubuntu-upgrade-linux-image-ibm-lts-20-04 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-hwe-16-04 ubuntu-upgrade-linux-image-lowlatency-hwe-18-04 ubuntu-upgrade-linux-image-lowlatency-hwe-20-04 ubuntu-upgrade-linux-image-lowlatency-lts-xenial ubuntu-upgrade-linux-image-nvidia ubuntu-upgrade-linux-image-nvidia-64k ubuntu-upgrade-linux-image-nvidia-lowlatency ubuntu-upgrade-linux-image-nvidia-lowlatency-64k ubuntu-upgrade-linux-image-oem 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-24-04 ubuntu-upgrade-linux-image-oem-24-04a ubuntu-upgrade-linux-image-oem-osp1 ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-64k ubuntu-upgrade-linux-image-oracle-lts-18-04 ubuntu-upgrade-linux-image-oracle-lts-20-04 ubuntu-upgrade-linux-image-oracle-lts-22-04 ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-hwe-18-04 ubuntu-upgrade-linux-image-raspi-nolpae ubuntu-upgrade-linux-image-raspi2 ubuntu-upgrade-linux-image-snapdragon-hwe-18-04 ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-16-04 ubuntu-upgrade-linux-image-virtual-hwe-18-04 ubuntu-upgrade-linux-image-virtual-hwe-20-04 ubuntu-upgrade-linux-image-virtual-hwe-24-04 ubuntu-upgrade-linux-image-virtual-lts-xenial ubuntu-upgrade-linux-image-xilinx-zynqmp References https://attackerkb.com/topics/cve-2024-36016 CVE - 2024-36016 USN-6921-1 USN-6921-2 USN-6923-1 USN-6923-2 USN-6924-1 USN-6924-2 USN-6926-1 USN-6926-2 USN-6926-3 USN-6927-1 USN-6938-1 USN-6952-1 USN-6952-2 USN-6953-1 USN-6956-1 USN-6957-1 USN-6979-1 USN-7019-1 View more

FreeBSD: VID-320A19F7-1DDD-11EF-A2AE-8C164567CA3C (CVE-2024-34161): nginx -- Multiple Vulnerabilities in HTTP/3 Severity 5 CVSS (AV:N/AC:L/Au:N/C:P/I:N/A:N) Published 05/29/2024 Created 06/01/2024 Added 05/30/2024 Modified 01/28/2025 Description When NGINX Plus or NGINX OSS are configured to use the HTTP/3 QUIC module and the network infrastructure supports a Maximum Transmission Unit (MTU) of 4096 or greater without fragmentation, undisclosed QUIC packets can cause NGINX worker processes to leak previously freed memory. Solution(s) freebsd-upgrade-package-nginx freebsd-upgrade-package-nginx-devel References CVE-2024-34161

FreeBSD: VID-320A19F7-1DDD-11EF-A2AE-8C164567CA3C (CVE-2024-31079): nginx -- Multiple Vulnerabilities in HTTP/3 Severity 6 CVSS (AV:N/AC:M/Au:N/C:N/I:P/A:P) Published 05/29/2024 Created 06/01/2024 Added 05/30/2024 Modified 01/28/2025 Description When NGINX Plus or NGINX OSS are configured to use the HTTP/3 QUIC module, undisclosed HTTP/3 requests can cause NGINX worker processes to terminate or cause other potential impact. This attack requires that a request be specifically timed during the connection draining process, which the attacker has no visibility and limited influence over. Solution(s) freebsd-upgrade-package-nginx freebsd-upgrade-package-nginx-devel References CVE-2024-31079

Debian: CVE-2023-52881: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: tcp: do not accept ACK of bytes we never sent This patch is based on a detailed report and ideas from Yepeng Pan and Christian Rossow. ACK seq validation is currently following RFC 5961 5.2 guidelines: The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT).All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back.It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored.If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return".The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable.This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through. This can be refined for new (and possibly spoofed) flows, by not accepting ACK for bytes that were never sent. This greatly improves TCP security at a little cost. I added a Fixes: tag to make sure this patch will reach stable trees, even if the 'blamed' patch was adhering to the RFC. tp->bytes_acked was added in linux-4.2 Following packetdrill test (courtesy of Yepeng Pan) shows the issue at hand: 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1024) = 0 // ---------------- Handshake ------------------- // // when window scale is set to 14 the window size can be extended to // 65535 * (2^14) = 1073725440. Linux would accept an ACK packet // with ack number in (Server_ISN+1-1073725440. Server_ISN+1) // ,though this ack number acknowledges some data never // sent by the server. +0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14> +0 > S. 0:0(0) ack 1 <...> +0 < . 1:1(0) ack 1 win 65535 +0 accept(3, ..., ...) = 4 // For the established connection, we send an ACK packet, // the ack packet uses ack number 1 - 1073725300 + 2^32, // where 2^32 is used to wrap around. // Note: we used 1073725300 instead of 1073725440 to avoid possible // edge cases. // 1 - 1073725300 + 2^32 = 3221241997 // Oops, old kernels happily accept this packet. +0 < . 1:1001(1000) ack 3221241997 win 65535 // After the kernel fix the following will be replaced by a challenge ACK, // and prior malicious frame would be dropped. +0 > . 1:1(0) ack 1001 Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2023-52881 CVE - 2023-52881

Debian: CVE-2024-36016: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 06/28/2024 Added 06/27/2024 Modified 06/27/2024 Description In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-36016 CVE - 2024-36016 DLA-3840-1

Huawei EulerOS: CVE-2024-36016: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 10/10/2024 Added 10/09/2024 Modified 10/09/2024 Description In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-36016 CVE - 2024-36016 EulerOS-SA-2024-2544

Huawei EulerOS: CVE-2023-52881: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: tcp: do not accept ACK of bytes we never sent This patch is based on a detailed report and ideas from Yepeng Pan and Christian Rossow. ACK seq validation is currently following RFC 5961 5.2 guidelines: The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT).All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back.It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored.If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return".The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable.This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through. This can be refined for new (and possibly spoofed) flows, by not accepting ACK for bytes that were never sent. This greatly improves TCP security at a little cost. I added a Fixes: tag to make sure this patch will reach stable trees, even if the 'blamed' patch was adhering to the RFC. tp->bytes_acked was added in linux-4.2 Following packetdrill test (courtesy of Yepeng Pan) shows the issue at hand: 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1024) = 0 // ---------------- Handshake ------------------- // // when window scale is set to 14 the window size can be extended to // 65535 * (2^14) = 1073725440. Linux would accept an ACK packet // with ack number in (Server_ISN+1-1073725440. Server_ISN+1) // ,though this ack number acknowledges some data never // sent by the server. +0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14> +0 > S. 0:0(0) ack 1 <...> +0 < . 1:1(0) ack 1 win 65535 +0 accept(3, ..., ...) = 4 // For the established connection, we send an ACK packet, // the ack packet uses ack number 1 - 1073725300 + 2^32, // where 2^32 is used to wrap around. // Note: we used 1073725300 instead of 1073725440 to avoid possible // edge cases. // 1 - 1073725300 + 2^32 = 3221241997 // Oops, old kernels happily accept this packet. +0 < . 1:1001(1000) ack 3221241997 win 65535 // After the kernel fix the following will be replaced by a challenge ACK, // and prior malicious frame would be dropped. +0 > . 1:1(0) ack 1001 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-2023-52881 CVE - 2023-52881 EulerOS-SA-2024-2394

Ubuntu: (Multiple Advisories) (CVE-2023-52882): Linux kernel vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/30/2024 Created 08/10/2024 Added 08/09/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change While PLL CPUX clock rate change when CPU is running from it works in vast majority of cases, now and then it causes instability. This leads to system crashes and other undefined behaviour. After a lot of testing (30+ hours) while also doing a lot of frequency switches, we can't observe any instability issues anymore when doing reparenting to stable clock like 24 MHz oscillator. Solution(s) ubuntu-upgrade-linux-image-5-15-0-1035-xilinx-zynqmp ubuntu-upgrade-linux-image-5-15-0-1050-gkeop ubuntu-upgrade-linux-image-5-15-0-1060-ibm ubuntu-upgrade-linux-image-5-15-0-1060-raspi ubuntu-upgrade-linux-image-5-15-0-1062-intel-iotg ubuntu-upgrade-linux-image-5-15-0-1062-nvidia ubuntu-upgrade-linux-image-5-15-0-1062-nvidia-lowlatency ubuntu-upgrade-linux-image-5-15-0-1064-gke ubuntu-upgrade-linux-image-5-15-0-1064-kvm ubuntu-upgrade-linux-image-5-15-0-1065-oracle ubuntu-upgrade-linux-image-5-15-0-1066-gcp ubuntu-upgrade-linux-image-5-15-0-1067-aws ubuntu-upgrade-linux-image-5-15-0-1070-azure ubuntu-upgrade-linux-image-5-15-0-1070-azure-fde ubuntu-upgrade-linux-image-5-15-0-118-generic ubuntu-upgrade-linux-image-5-15-0-118-generic-64k ubuntu-upgrade-linux-image-5-15-0-118-generic-lpae ubuntu-upgrade-linux-image-5-15-0-118-lowlatency ubuntu-upgrade-linux-image-5-15-0-118-lowlatency-64k ubuntu-upgrade-linux-image-5-4-0-1042-iot ubuntu-upgrade-linux-image-5-4-0-1049-xilinx-zynqmp ubuntu-upgrade-linux-image-5-4-0-1077-ibm ubuntu-upgrade-linux-image-5-4-0-1090-bluefield ubuntu-upgrade-linux-image-5-4-0-1097-gkeop ubuntu-upgrade-linux-image-5-4-0-1114-raspi ubuntu-upgrade-linux-image-5-4-0-1118-kvm ubuntu-upgrade-linux-image-5-4-0-1129-oracle ubuntu-upgrade-linux-image-5-4-0-1130-aws ubuntu-upgrade-linux-image-5-4-0-1134-gcp ubuntu-upgrade-linux-image-5-4-0-1135-azure ubuntu-upgrade-linux-image-5-4-0-192-generic ubuntu-upgrade-linux-image-5-4-0-192-generic-lpae ubuntu-upgrade-linux-image-5-4-0-192-lowlatency ubuntu-upgrade-linux-image-6-8-0-1008-gke ubuntu-upgrade-linux-image-6-8-0-1009-raspi ubuntu-upgrade-linux-image-6-8-0-1010-ibm ubuntu-upgrade-linux-image-6-8-0-1010-oem ubuntu-upgrade-linux-image-6-8-0-1010-oracle ubuntu-upgrade-linux-image-6-8-0-1010-oracle-64k ubuntu-upgrade-linux-image-6-8-0-1011-nvidia ubuntu-upgrade-linux-image-6-8-0-1011-nvidia-64k ubuntu-upgrade-linux-image-6-8-0-1011-nvidia-lowlatency ubuntu-upgrade-linux-image-6-8-0-1011-nvidia-lowlatency-64k ubuntu-upgrade-linux-image-6-8-0-1012-azure ubuntu-upgrade-linux-image-6-8-0-1012-azure-fde ubuntu-upgrade-linux-image-6-8-0-1012-gcp ubuntu-upgrade-linux-image-6-8-0-1013-aws ubuntu-upgrade-linux-image-6-8-0-40-generic ubuntu-upgrade-linux-image-6-8-0-40-generic-64k ubuntu-upgrade-linux-image-6-8-0-40-lowlatency ubuntu-upgrade-linux-image-6-8-0-40-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-aws-lts-20-04 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-20-04 ubuntu-upgrade-linux-image-azure-lts-22-04 ubuntu-upgrade-linux-image-bluefield ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-gcp-lts-20-04 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-24-04 ubuntu-upgrade-linux-image-generic-hwe-18-04 ubuntu-upgrade-linux-image-generic-hwe-20-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-5-4 ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-classic ubuntu-upgrade-linux-image-ibm-lts-20-04 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-hwe-18-04 ubuntu-upgrade-linux-image-lowlatency-hwe-20-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 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-24-04 ubuntu-upgrade-linux-image-oem-24-04a ubuntu-upgrade-linux-image-oem-osp1 ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-64k ubuntu-upgrade-linux-image-oracle-lts-20-04 ubuntu-upgrade-linux-image-oracle-lts-22-04 ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-hwe-18-04 ubuntu-upgrade-linux-image-raspi-nolpae ubuntu-upgrade-linux-image-raspi2 ubuntu-upgrade-linux-image-snapdragon-hwe-18-04 ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-18-04 ubuntu-upgrade-linux-image-virtual-hwe-20-04 ubuntu-upgrade-linux-image-virtual-hwe-24-04 ubuntu-upgrade-linux-image-xilinx-zynqmp References https://attackerkb.com/topics/cve-2023-52882 CVE - 2023-52882 USN-6949-1 USN-6949-2 USN-6950-1 USN-6950-2 USN-6950-3 USN-6950-4 USN-6951-1 USN-6951-2 USN-6951-3 USN-6951-4 USN-6952-1 USN-6952-2 USN-6953-1 USN-6955-1 USN-6956-1 USN-6957-1 USN-6979-1 USN-7019-1 View more

Microsoft Edge Chromium: CVE-2024-5495 Use after free in Dawn Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 05/30/2024 Created 06/04/2024 Added 06/04/2024 Modified 01/28/2025 Description Use after free in Dawn in Google Chrome prior to 125.0.6422.141 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-5495 CVE - 2024-5495 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-5495

Rocky Linux: CVE-2024-36016: kernel-rt (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 08/23/2024 Added 08/22/2024 Modified 11/18/2024 Description In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size. 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-36016 CVE - 2024-36016 https://errata.rockylinux.org/RLSA-2024:5101 https://errata.rockylinux.org/RLSA-2024:5102

Huawei EulerOS: CVE-2024-36016: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size. 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-36016 CVE - 2024-36016 EulerOS-SA-2024-2207

Huawei EulerOS: CVE-2024-35221: ruby security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 10/10/2024 Added 10/09/2024 Modified 10/09/2024 Description Rubygems.org is the Ruby community's gem hosting service. A Gem publisher can cause a Remote DoS when publishing a Gem. This is due to how Ruby reads the Manifest of Gem files when using Gem::Specification.from_yaml. from_yaml makes use of SafeYAML.load which allows YAML aliases inside the YAML-based metadata of a gem. YAML aliases allow for Denial of Service attacks with so-called `YAML-bombs` (comparable to Billion laughs attacks). This was patched. There is is no action required by users. This issue is also tracked as GHSL-2024-001 and was discovered by the GitHub security lab. Solution(s) huawei-euleros-2_0_sp12-upgrade-ruby huawei-euleros-2_0_sp12-upgrade-ruby-help huawei-euleros-2_0_sp12-upgrade-ruby-irb References https://attackerkb.com/topics/cve-2024-35221 CVE - 2024-35221 EulerOS-SA-2024-2542

FreeBSD: VID-320A19F7-1DDD-11EF-A2AE-8C164567CA3C (CVE-2024-35200): nginx -- Multiple Vulnerabilities in HTTP/3 Severity 5 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:P) Published 05/29/2024 Created 06/01/2024 Added 05/30/2024 Modified 01/28/2025 Description When NGINX Plus or NGINX OSS are configured to use the HTTP/3 QUIC module, undisclosed HTTP/3 requests can cause NGINX worker processes to terminate. Solution(s) freebsd-upgrade-package-nginx freebsd-upgrade-package-nginx-devel References CVE-2024-35200

SUSE: CVE-2024-36016: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 06/14/2024 Added 06/13/2024 Modified 08/28/2024 Description In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size. 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-base 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-man 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-36016 CVE - 2024-36016

SUSE: CVE-2024-35434: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/29/2024 Created 06/24/2024 Added 06/24/2024 Modified 06/24/2024 Description Irontec Sngrep v1.8.1 was discovered to contain a heap buffer overflow via the function rtp_check_packet at /sngrep/src/rtp.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted SIP packet. Solution(s) suse-upgrade-sngrep References https://attackerkb.com/topics/cve-2024-35434 CVE - 2024-35434