ISHACK AI BOT

FreeBSD: VID-71F3E9F0-BAFC-11EF-885D-901B0E934D69 (CVE-2024-52805): py-matrix-synapse -- multiple vulnerabilities in versions prior to 1.120.1 Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/03/2024 Created 12/19/2024 Added 12/18/2024 Modified 12/18/2024 Description Synapse is an open-source Matrix homeserver. In Synapse before 1.120.1, multipart/form-data requests can in certain configurations transiently increase memory consumption beyond expected levels while processing the request, which can be used to amplify denial of service attacks. Synapse 1.120.1 resolves the issue by denying requests with unsupported multipart/form-data content type. Solution(s) freebsd-upgrade-package-py310-matrix-synapse freebsd-upgrade-package-py311-matrix-synapse freebsd-upgrade-package-py38-matrix-synapse freebsd-upgrade-package-py39-matrix-synapse References CVE-2024-52805

Veeam Backup and Replication: Missing Authentication for Critical Function (CVE-2024-42455) Severity 8 CVSS (AV:N/AC:L/Au:S/C:N/I:P/A:C) Published 12/03/2024 Created 02/07/2025 Added 02/06/2025 Modified 02/06/2025 Description A vulnerability that allows an authenticated user with a role assigned in the Users and Roles settings on the backup server to connect to remote services and exploit insecure deserialization by sending a serialized temporary file collection, thereby enabling the deletion of any file on the system with service account privileges. Solution(s) veeam-backup-and-replication-upgrade-latest References https://attackerkb.com/topics/cve-2024-42455 CVE - 2024-42455 https://www.veeam.com/kb4693

Veeam Backup and Replication: None (CVE-2024-45204) Severity 7 CVSS (AV:N/AC:L/Au:S/C:C/I:N/A:N) Published 12/03/2024 Created 02/07/2025 Added 02/06/2025 Modified 02/06/2025 Description A vulnerability that allows an authenticated user with an assigned role in the Users and Roles settings on the backup server to exploit insufficient permissions in credential handling, potentially leading to the leakage of NTLM hashes of saved credentials. Solution(s) veeam-backup-and-replication-upgrade-latest References https://attackerkb.com/topics/cve-2024-45204 CVE - 2024-45204 https://www.veeam.com/kb4693

Veeam Backup and Replication: Other (CVE-2024-40717) Severity 9 CVSS (AV:N/AC:L/Au:S/C:C/I:C/A:C) Published 12/03/2024 Created 02/07/2025 Added 02/06/2025 Modified 02/06/2025 Description A vulnerability allows an authenticated user with a role assigned in the Users and Roles settings on the backup server to execute a script with elevated privileges by configuring it as a pre-job or post-job task, thereby causing the script to be executed as LocalSystem. Solution(s) veeam-backup-and-replication-upgrade-latest References https://attackerkb.com/topics/cve-2024-40717 CVE - 2024-40717 https://www.veeam.com/kb4693

FreeBSD: VID-71F3E9F0-BAFC-11EF-885D-901B0E934D69 (CVE-2024-52815): py-matrix-synapse -- multiple vulnerabilities in versions prior to 1.120.1 Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/03/2024 Created 12/19/2024 Added 12/18/2024 Modified 12/18/2024 Description Synapse is an open-source Matrix homeserver. Synapse versions before 1.120.1 fail to properly validate invites received over federation. This vulnerability allows a malicious server to send a specially crafted invite that disrupts the invited user's /sync functionality. Synapse 1.120.1 rejects such invalid invites received over federation and restores the ability to sync for affected users. Solution(s) freebsd-upgrade-package-py310-matrix-synapse freebsd-upgrade-package-py311-matrix-synapse freebsd-upgrade-package-py38-matrix-synapse freebsd-upgrade-package-py39-matrix-synapse References CVE-2024-52815

Cleo LexiCom: CVE-2024-50623: Unauthenticated Remote Execution Severity 10 CVSS (AV:N/AC:L/Au:N/C:C/I:C/A:C) Published 12/03/2024 Created 12/24/2024 Added 12/23/2024 Modified 12/24/2024 Description In Cleo LexiCom, prior version 5.8.0.21, there is an unrestricted file upload and download vulnerability that could lead to remote execution. Solution(s) cleo-lexicom-upgrade-cve-2024-50623-remote References https://attackerkb.com/topics/cve-2024-50623 CVE - 2024-50623 https://support.cleo.com/hc/en-us/articles/27140294267799-Cleo-Product-Security-Advisory-CVE-2024-50623

Debian: CVE-2024-53130: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/04/2024 Created 12/10/2024 Added 12/09/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the "uptodate" state for each of its caller block reading functions.However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-53130 CVE - 2024-53130 DLA-4008-1

Oracle Linux: CVE-2024-53140: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/04/2024 Created 02/12/2025 Added 02/10/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump- actual dump helper, keeps getting called until it returns 0 - done- (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-53140 CVE - 2024-53140 ELSA-2025-20095 ELSA-2025-20100

VMware Photon OS: CVE-2024-53125 Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/04/2024 Created 01/21/2025 Added 01/20/2025 Modified 01/20/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: sync_linked_regs() must preserve subreg_def Range propagation must not affect subreg_def marks, otherwise the following example is rewritten by verifier incorrectly when BPF_F_TEST_RND_HI32 flag is set: 0: call bpf_ktime_get_ns call bpf_ktime_get_ns 1: r0 &= 0x7fffffff after verifier r0 &= 0x7fffffff 2: w1 = w0rewrites w1 = w0 3: if w0 < 10 goto +0 -------------->r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11(r) 6: exit; if w0 < 0xa goto pc+0 r1 >>= 32 r0 = r1 exit (or zero extension of w1 at (2) is missing for architectures that require zero extension for upper register half). The following happens w/o this patch: - r0 is marked as not a subreg at (0); - w1 is marked as subreg at (2); - w1 subreg_def is overridden at (3) by copy_register_state(); - w1 is read at (5) but mark_insn_zext() does not mark (2) for zero extension, because w1 subreg_def is not set; - because of BPF_F_TEST_RND_HI32 flag verifier inserts random value for hi32 bits of (2) (marked (r)); - this random value is read at (5). Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-53125 CVE - 2024-53125

VMware Photon OS: CVE-2024-53135 Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/04/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y.There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check).Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the "load IA32_RTIT_CTL" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit.E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-53135 CVE - 2024-53135

VMware Photon OS: CVE-2024-53140 Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/04/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump- actual dump helper, keeps getting called until it returns 0 - done- (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-53140 CVE - 2024-53140

Debian: CVE-2024-53125: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/04/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: sync_linked_regs() must preserve subreg_def Range propagation must not affect subreg_def marks, otherwise the following example is rewritten by verifier incorrectly when BPF_F_TEST_RND_HI32 flag is set: 0: call bpf_ktime_get_ns call bpf_ktime_get_ns 1: r0 &= 0x7fffffff after verifier r0 &= 0x7fffffff 2: w1 = w0rewrites w1 = w0 3: if w0 < 10 goto +0 -------------->r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11(r) 6: exit; if w0 < 0xa goto pc+0 r1 >>= 32 r0 = r1 exit (or zero extension of w1 at (2) is missing for architectures that require zero extension for upper register half). The following happens w/o this patch: - r0 is marked as not a subreg at (0); - w1 is marked as subreg at (2); - w1 subreg_def is overridden at (3) by copy_register_state(); - w1 is read at (5) but mark_insn_zext() does not mark (2) for zero extension, because w1 subreg_def is not set; - because of BPF_F_TEST_RND_HI32 flag verifier inserts random value for hi32 bits of (2) (marked (r)); - this random value is read at (5). Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-53125 CVE - 2024-53125

Debian: CVE-2024-53136: linux, linux-6.1 -- security update Severity 4 CVSS (AV:L/AC:M/Au:S/C:N/I:N/A:C) Published 12/04/2024 Created 12/10/2024 Added 12/09/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: mm: revert "mm: shmem: fix data-race in shmem_getattr()" Revert d949d1d14fa2 ("mm: shmem: fix data-race in shmem_getattr()") as suggested by Chuck [1].It is causing deadlocks when accessing tmpfs over NFS. As Hugh commented, "added just to silence a syzbot sanitizer splat: added where there has never been any practical problem". Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-53136 CVE - 2024-53136 DLA-4008-1

Oracle Linux: CVE-2024-53130: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/04/2024 Created 02/12/2025 Added 02/10/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the &quot;block:block_dirty_buffer&quot; tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh-&gt;b_bdev-&gt;bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the &quot;uptodate&quot; state for each of its caller block reading functions.However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh-&gt;b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer&apos;s uptodate flag. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-53130 CVE - 2024-53130 ELSA-2025-20095 ELSA-2025-20100

Debian: CVE-2024-53129: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/04/2024 Created 12/10/2024 Added 12/09/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077) Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-53129 CVE - 2024-53129 DLA-4008-1

Debian: CVE-2024-53131: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/04/2024 Created 12/10/2024 Added 12/09/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using "block:block_touch_buffer" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure.In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-53131 CVE - 2024-53131 DLA-4008-1

Cisco UCS Manager: CVE-2024-20397: Cisco NX-OS Software Image Verification Bypass Vulnerability Severity 6 CVSS (AV:L/AC:L/Au:N/C:P/I:C/A:N) Published 12/04/2024 Created 12/06/2024 Added 12/05/2024 Modified 02/14/2025 Description A vulnerability in the bootloader of Cisco NX-OS Software could allow an unauthenticated attacker with physical access to an affected device, or an authenticated, local attacker with administrative credentials, to bypass NX-OS image signature verification. This vulnerability is due to insecure bootloader settings. An attacker could exploit this vulnerability by executing a series of bootloader commands. A successful exploit could allow the attacker to bypass NX-OS image signature verification and load unverified software. Solution(s) cisco-ucs-manager-upgrade-latest References https://attackerkb.com/topics/cve-2024-20397 CVE - 2024-20397 https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-nxos-image-sig-bypas-pQDRQvjL cisco-sa-nxos-image-sig-bypas-pQDRQvjL

Red Hat: CVE-2024-53122: kernel: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust (Multiple Advisories) Severity 5 CVSS (AV:N/AC:H/Au:N/C:N/I:N/A:C) Published 12/02/2024 Created 01/11/2025 Added 01/10/2025 Modified 01/10/2025 Description In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf(). Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-53122 RHSA-2025:0049 RHSA-2025:0051 RHSA-2025:0052 RHSA-2025:0054 RHSA-2025:0057 RHSA-2025:0059 RHSA-2025:0062 RHSA-2025:0063 RHSA-2025:0064 RHSA-2025:0065 RHSA-2025:0066 RHSA-2025:0109 View more

Huawei EulerOS: CVE-2024-53104: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/02/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming. 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-53104 CVE - 2024-53104 EulerOS-SA-2025-1192

Debian: CVE-2024-52596: simplesamlphp -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/02/2024 Created 12/10/2024 Added 12/09/2024 Modified 12/09/2024 Description SimpleSAMLphp xml-common is a common classes for handling XML-structures. When loading an (untrusted) XML document, for example the SAMLResponse, it's possible to induce an XXE. This vulnerability is fixed in 1.19.0. Solution(s) debian-upgrade-simplesamlphp References https://attackerkb.com/topics/cve-2024-52596 CVE - 2024-52596 DLA-3981-1 DSA-5822-1

Debian: CVE-2024-53120: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/02/2024 Created 12/10/2024 Added 12/09/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-53120 CVE - 2024-53120 DLA-4008-1

Debian: CVE-2024-53123: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/02/2024 Created 12/10/2024 Added 12/09/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 <f7> 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7feb5d857559 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-53123 CVE - 2024-53123 DLA-4008-1

Huawei EulerOS: CVE-2024-53119: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/02/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00(..@............ backtrace (crc 9e5f4e84): [<ffffffff81418ff1>] kmem_cache_alloc_noprof+0x2c1/0x360 [<ffffffff81d27aa0>] sk_prot_alloc+0x30/0x120 [<ffffffff81d2b54c>] sk_alloc+0x2c/0x4b0 [<ffffffff81fe049a>] __vsock_create.constprop.0+0x2a/0x310 [<ffffffff81fe6d6c>] virtio_transport_recv_pkt+0x4dc/0x9a0 [<ffffffff81fe745d>] vsock_loopback_work+0xfd/0x140 [<ffffffff810fc6ac>] process_one_work+0x20c/0x570 [<ffffffff810fce3f>] worker_thread+0x1bf/0x3a0 [<ffffffff811070dd>] kthread+0xdd/0x110 [<ffffffff81044fdd>] ret_from_fork+0x2d/0x50 [<ffffffff8100785a>] ret_from_fork_asm+0x1a/0x30 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-53119 CVE - 2024-53119 EulerOS-SA-2025-1159

Huawei EulerOS: CVE-2024-53124: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/02/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS:0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768= 7424 | sk_mem_charge() | -768= 6656 ... |...| sk_mem_uncharge() | | +768= 7424 reclaimable=7424| | | sk_mem_uncharge() | +768= 8192 | reclaimable=8192| __sk_mem_reclaim()| | -4096 = 4096 | __sk_mem_reclaim()| -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv(). 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-53124 CVE - 2024-53124 EulerOS-SA-2025-1192

Alma Linux: CVE-2024-53122: Important: kernel security update (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/02/2024 Created 01/10/2025 Added 01/09/2025 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf(). Solution(s) alma-upgrade-bpftool alma-upgrade-kernel alma-upgrade-kernel-64k alma-upgrade-kernel-64k-core alma-upgrade-kernel-64k-debug alma-upgrade-kernel-64k-debug-core alma-upgrade-kernel-64k-debug-devel alma-upgrade-kernel-64k-debug-devel-matched alma-upgrade-kernel-64k-debug-modules alma-upgrade-kernel-64k-debug-modules-core alma-upgrade-kernel-64k-debug-modules-extra alma-upgrade-kernel-64k-devel alma-upgrade-kernel-64k-devel-matched alma-upgrade-kernel-64k-modules alma-upgrade-kernel-64k-modules-core alma-upgrade-kernel-64k-modules-extra alma-upgrade-kernel-abi-stablelists alma-upgrade-kernel-core alma-upgrade-kernel-cross-headers alma-upgrade-kernel-debug alma-upgrade-kernel-debug-core alma-upgrade-kernel-debug-devel alma-upgrade-kernel-debug-devel-matched alma-upgrade-kernel-debug-modules alma-upgrade-kernel-debug-modules-core alma-upgrade-kernel-debug-modules-extra alma-upgrade-kernel-debug-uki-virt alma-upgrade-kernel-devel alma-upgrade-kernel-devel-matched alma-upgrade-kernel-doc alma-upgrade-kernel-headers alma-upgrade-kernel-modules alma-upgrade-kernel-modules-core alma-upgrade-kernel-modules-extra alma-upgrade-kernel-rt alma-upgrade-kernel-rt-core alma-upgrade-kernel-rt-debug alma-upgrade-kernel-rt-debug-core alma-upgrade-kernel-rt-debug-devel alma-upgrade-kernel-rt-debug-modules alma-upgrade-kernel-rt-debug-modules-core alma-upgrade-kernel-rt-debug-modules-extra alma-upgrade-kernel-rt-devel alma-upgrade-kernel-rt-modules alma-upgrade-kernel-rt-modules-core alma-upgrade-kernel-rt-modules-extra alma-upgrade-kernel-tools alma-upgrade-kernel-tools-libs alma-upgrade-kernel-tools-libs-devel alma-upgrade-kernel-uki-virt alma-upgrade-kernel-uki-virt-addons alma-upgrade-kernel-zfcpdump alma-upgrade-kernel-zfcpdump-core alma-upgrade-kernel-zfcpdump-devel alma-upgrade-kernel-zfcpdump-devel-matched alma-upgrade-kernel-zfcpdump-modules alma-upgrade-kernel-zfcpdump-modules-core alma-upgrade-kernel-zfcpdump-modules-extra alma-upgrade-libperf alma-upgrade-perf alma-upgrade-python3-perf alma-upgrade-rtla alma-upgrade-rv References https://attackerkb.com/topics/cve-2024-53122 CVE - 2024-53122 https://errata.almalinux.org/8/ALSA-2025-0065.html https://errata.almalinux.org/8/ALSA-2025-0066.html https://errata.almalinux.org/9/ALSA-2025-0059.html