ISHACK AI BOT

Ubuntu: (Multiple Advisories) (CVE-2024-49963): Linux kernel vulnerabilities Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 12/19/2024 Added 12/18/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs Solution(s) ubuntu-upgrade-linux-image-5-15-0-1039-xilinx-zynqmp ubuntu-upgrade-linux-image-5-15-0-1056-gkeop ubuntu-upgrade-linux-image-5-15-0-1066-ibm ubuntu-upgrade-linux-image-5-15-0-1066-raspi ubuntu-upgrade-linux-image-5-15-0-1068-nvidia ubuntu-upgrade-linux-image-5-15-0-1068-nvidia-lowlatency ubuntu-upgrade-linux-image-5-15-0-1070-gke ubuntu-upgrade-linux-image-5-15-0-1070-kvm ubuntu-upgrade-linux-image-5-15-0-1071-intel-iotg ubuntu-upgrade-linux-image-5-15-0-1071-oracle ubuntu-upgrade-linux-image-5-15-0-1072-gcp ubuntu-upgrade-linux-image-5-15-0-1073-aws ubuntu-upgrade-linux-image-5-15-0-1078-azure ubuntu-upgrade-linux-image-5-15-0-127-generic ubuntu-upgrade-linux-image-5-15-0-127-generic-64k ubuntu-upgrade-linux-image-5-15-0-127-generic-lpae ubuntu-upgrade-linux-image-5-15-0-127-lowlatency ubuntu-upgrade-linux-image-5-15-0-127-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-aws-lts-22-04 ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-cvm ubuntu-upgrade-linux-image-azure-lts-22-04 ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-gcp-lts-22-04 ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-20-04 ubuntu-upgrade-linux-image-generic-hwe-20-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-ibm 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-20-04 ubuntu-upgrade-linux-image-nvidia ubuntu-upgrade-linux-image-nvidia-lowlatency 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-oracle ubuntu-upgrade-linux-image-oracle-lts-22-04 ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-nolpae ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-20-04 ubuntu-upgrade-linux-image-xilinx-zynqmp References https://attackerkb.com/topics/cve-2024-49963 CVE - 2024-49963 USN-7166-1 USN-7166-2 USN-7166-3 USN-7166-4 USN-7186-1 USN-7186-2 USN-7194-1 View more

Amazon Linux AMI 2: CVE-2024-49960: Security patch for kernel-livepatch-5.10.227-219.884, kernel-livepatch-5.10.228-219.884, kernel-livepatch-5.10.230-223.885, kernel-livepatch-5.10.233-223.887 (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/05/2025 Added 02/04/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd. Solution(s) amazon-linux-ami-2-upgrade-kernel-livepatch-5-10-227-219-884 amazon-linux-ami-2-upgrade-kernel-livepatch-5-10-228-219-884 amazon-linux-ami-2-upgrade-kernel-livepatch-5-10-230-223-885 amazon-linux-ami-2-upgrade-kernel-livepatch-5-10-233-223-887 References https://attackerkb.com/topics/cve-2024-49960 AL2/ALASLIVEPATCH-2025-195 AL2/ALASLIVEPATCH-2025-196 AL2/ALASLIVEPATCH-2025-197 AL2/ALASLIVEPATCH-2025-198 CVE - 2024-49960

VMware Photon OS: CVE-2024-50047 Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 10/21/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: smb: client: fix UAF in async decryption Doing an async decryption (large read) crashes with a slab-use-after-free way down in the crypto API. Reproducer: # mount.cifs -o ...,seal,esize=1 //srv/share /mnt # dd if=/mnt/largefile of=/dev/null ... [194.196391] ================================================================== [194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110 [194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899 [194.197707] [194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43 [194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 [194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs] [194.200032] Call Trace: [194.200191]<TASK> [194.200327]dump_stack_lvl+0x4e/0x70 [194.200558]? gf128mul_4k_lle+0xc1/0x110 [194.200809]print_report+0x174/0x505 [194.201040]? __pfx__raw_spin_lock_irqsave+0x10/0x10 [194.201352]? srso_return_thunk+0x5/0x5f [194.201604]? __virt_addr_valid+0xdf/0x1c0 [194.201868]? gf128mul_4k_lle+0xc1/0x110 [194.202128]kasan_report+0xc8/0x150 [194.202361]? gf128mul_4k_lle+0xc1/0x110 [194.202616]gf128mul_4k_lle+0xc1/0x110 [194.202863]ghash_update+0x184/0x210 [194.203103]shash_ahash_update+0x184/0x2a0 [194.203377]? __pfx_shash_ahash_update+0x10/0x10 [194.203651]? srso_return_thunk+0x5/0x5f [194.203877]? crypto_gcm_init_common+0x1ba/0x340 [194.204142]gcm_hash_assoc_remain_continue+0x10a/0x140 [194.204434]crypt_message+0xec1/0x10a0 [cifs] [194.206489]? __pfx_crypt_message+0x10/0x10 [cifs] [194.208507]? srso_return_thunk+0x5/0x5f [194.209205]? srso_return_thunk+0x5/0x5f [194.209925]? srso_return_thunk+0x5/0x5f [194.210443]? srso_return_thunk+0x5/0x5f [194.211037]decrypt_raw_data+0x15f/0x250 [cifs] [194.212906]? __pfx_decrypt_raw_data+0x10/0x10 [cifs] [194.214670]? srso_return_thunk+0x5/0x5f [194.215193]smb2_decrypt_offload+0x12a/0x6c0 [cifs] This is because TFM is being used in parallel. Fix this by allocating a new AEAD TFM for async decryption, but keep the existing one for synchronous READ cases (similar to what is done in smb3_calc_signature()). Also remove the calls to aead_request_set_callback() and crypto_wait_req() since it's always going to be a synchronous operation. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-50047 CVE - 2024-50047

Debian: CVE-2023-52917: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2023-52917 CVE - 2023-52917 DLA-4008-1

VMware Photon OS: CVE-2024-50000 Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-50000 CVE - 2024-50000

Debian: CVE-2024-49974: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 12/03/2024 Added 12/02/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-49974 CVE - 2024-49974 DSA-5818-1

Debian: CVE-2024-49973: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-49973 CVE - 2024-49973 DLA-4008-1

Debian: CVE-2024-49963: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-49963 CVE - 2024-49963 DLA-4008-1

Debian: CVE-2024-49959: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-49959 CVE - 2024-49959 DLA-4008-1

Debian: CVE-2024-49958: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption.Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227.Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the "Next Free Rec:" had overshot the "Count:" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## OffsetClusters Block# 00 2310 2776351 123102139 2777375 244491221 2778399 356707312779423 464015662780447 ........... ....... ........... ....... The issue was in the reflink workfow while reserving space for inline xattr.The problematic function is ocfs2_reflink_xattr_inline().By the time this function is called the reflink tree is already recreated at the destination inode from the source inode.At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block.It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-49958 CVE - 2024-49958 DLA-4008-1

Debian: CVE-2024-49927: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-49927 CVE - 2024-49927 DLA-4008-1

Debian: CVE-2024-49925: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-49925 CVE - 2024-49925

Debian: CVE-2024-49913: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906) Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-49913 CVE - 2024-49913 DLA-4008-1

Debian: CVE-2024-49912: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774) Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-49912 CVE - 2024-49912 DLA-4008-1

Huawei EulerOS: CVE-2024-49883: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: <TASK> ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem. 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-49883 CVE - 2024-49883 EulerOS-SA-2025-1159

Huawei EulerOS: CVE-2022-49006: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 10/21/2024 Created 12/13/2024 Added 12/12/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: tracing: Free buffers when a used dynamic event is removed After 65536 dynamic events have been added and removed, the "type" field of the event then uses the first type number that is available (not currently used by other events). A type number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be created and destroyed), if another dynamic event is created that has the same number that new event's logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will remove the old event and create a new one (with the same format) and increase the type number to the next available on until the type number reaches over 65535 which is the max number for the 16 bit type. After it reaches that number, the logic to allocate a new number simply looks for the next available number. When an dynamic event is removed, that number is then available to be reused by the next dynamic event created. That is, once the above reaches the max number, the number assigned to the event in that loop will remain the same. Now that means deleting one dynamic event and created another will reuse the previous events type number. This is where bad things can happen. After the above loop finishes, the kprobes/foo event which reads the do_sys_openat2 function call's first parameter as an integer. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211[005] ....2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211[005] ....2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211[005] ....2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211[005] ....2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Now if we delete the kprobe and create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events And now we can the trace: # cat trace sendmail-1942[002] ..... 530.136320: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046[004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1="????????????????????????????????????????????????????????????????????????????????????????????????" cat-2046[004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1="????????????????????????????????????????????????????????????????????????????????????????????????" cat-2046[004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1="????????????????????????????????????????????????????????????????????????????????????????????????" cat-2046[004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1="??????????????????????????????????????? ---truncated--- 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-2022-49006 CVE - 2022-49006 EulerOS-SA-2024-2953

Huawei EulerOS: CVE-2022-48949: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: igb: Initialize mailbox message for VF reset When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case. 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-2022-48949 CVE - 2022-48949 EulerOS-SA-2025-1192

Ubuntu: (Multiple Advisories) (CVE-2024-49895): Linux kernel vulnerabilities Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 10/21/2024 Created 12/19/2024 Added 12/18/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 colormanagement module. The issue could occur when the index 'i' exceeds thenumber of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max Solution(s) ubuntu-upgrade-linux-image-5-15-0-1039-xilinx-zynqmp ubuntu-upgrade-linux-image-5-15-0-1056-gkeop ubuntu-upgrade-linux-image-5-15-0-1066-ibm ubuntu-upgrade-linux-image-5-15-0-1066-raspi ubuntu-upgrade-linux-image-5-15-0-1068-nvidia ubuntu-upgrade-linux-image-5-15-0-1068-nvidia-lowlatency ubuntu-upgrade-linux-image-5-15-0-1070-gke ubuntu-upgrade-linux-image-5-15-0-1070-kvm ubuntu-upgrade-linux-image-5-15-0-1071-intel-iotg ubuntu-upgrade-linux-image-5-15-0-1071-oracle ubuntu-upgrade-linux-image-5-15-0-1072-gcp ubuntu-upgrade-linux-image-5-15-0-1073-aws ubuntu-upgrade-linux-image-5-15-0-1078-azure ubuntu-upgrade-linux-image-5-15-0-127-generic ubuntu-upgrade-linux-image-5-15-0-127-generic-64k ubuntu-upgrade-linux-image-5-15-0-127-generic-lpae ubuntu-upgrade-linux-image-5-15-0-127-lowlatency ubuntu-upgrade-linux-image-5-15-0-127-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-aws-lts-22-04 ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-cvm ubuntu-upgrade-linux-image-azure-lts-22-04 ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-gcp-lts-22-04 ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-20-04 ubuntu-upgrade-linux-image-generic-hwe-20-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-ibm 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-20-04 ubuntu-upgrade-linux-image-nvidia ubuntu-upgrade-linux-image-nvidia-lowlatency 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-oracle ubuntu-upgrade-linux-image-oracle-lts-22-04 ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-nolpae ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-20-04 ubuntu-upgrade-linux-image-xilinx-zynqmp References https://attackerkb.com/topics/cve-2024-49895 CVE - 2024-49895 USN-7166-1 USN-7166-2 USN-7166-3 USN-7166-4 USN-7186-1 USN-7186-2 USN-7194-1 View more

Debian: CVE-2024-47690: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-47690 CVE - 2024-47690 DLA-4008-1

Debian: CVE-2024-47697: linux, linux-6.1 -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-47697 CVE - 2024-47697 DLA-4008-1

Debian: CVE-2024-47679: linux, linux-6.1 -- security update Severity 4 CVSS (AV:L/AC:M/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0:cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final()generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before// inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode)// schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput()->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/[email protected]/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-47679 CVE - 2024-47679 DLA-4008-1

Debian: CVE-2024-47706: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: Process 1 Process 2 Process 3 (BIC1)(BIC2) (BIC3) |?|? |? |||| || V|V| V| bfqq1 bfqq2 bfqq3 process ref: 1 1 1 2) bfqq1 merged to bfqq2: Process 1 Process 2 Process 3 (BIC1)(BIC2) (BIC3) | | |? \--------------\| || V V| bfqq1--------->bfqq2 bfqq3 process ref: 0 2 1 3) bfqq2 merged to bfqq3: Process 1 Process 2 Process 3 (BIC1)(BIC2) (BIC3) here -> ?| | \--------------\ \-------------\| V V bfqq1--------->bfqq2---------->bfqq3 process ref: 0 1 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 </TASK> Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated--- Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-47706 CVE - 2024-47706 DLA-4008-1

Huawei EulerOS: CVE-2024-49948: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/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: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len. 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-49948 CVE - 2024-49948 EulerOS-SA-2025-1159

Huawei EulerOS: CVE-2024-49944: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: <TASK> __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline] 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-49944 CVE - 2024-49944 EulerOS-SA-2025-1159

Huawei EulerOS: CVE-2024-49940: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case. 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-49940 CVE - 2024-49940 EulerOS-SA-2025-1159