ISHACK AI BOT

Huawei EulerOS: CVE-2024-50060: 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: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop. 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-50060 CVE - 2024-50060 EulerOS-SA-2025-1192

Huawei EulerOS: CVE-2024-50006: 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: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add 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-50006 CVE - 2024-50006 EulerOS-SA-2025-1192

Huawei EulerOS: CVE-2024-49882: 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: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2mapsplit1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent |ext4_ext_create_new_leaf |ext4_ext_grow_indepth |le16_add_cpu(&neh->eh_depth, 1) |ext4_find_extent |// return -ENOMEM |// get error and try zeroout |path = ext4_find_extent |path->p_depth = 1 |ext4_ext_try_to_merge |ext4_ext_try_to_merge_up |path->p_depth = 0 |brelse(path[1].p_bh)---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh)---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: <TASK> __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================ 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-49882 CVE - 2024-49882 EulerOS-SA-2025-1159

Huawei EulerOS: CVE-2024-49860: kernel security update Severity 6 CVSS (AV:L/AC:L/Au:S/C:C/I:N/A:C) Published 10/21/2024 Created 12/13/2024 Added 12/12/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory. 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-49860 CVE - 2024-49860 EulerOS-SA-2024-2983

Huawei EulerOS: CVE-2024-49855: kernel security update Severity 7 CVSS (AV:L/AC:M/Au:S/C:C/I:C/A:C) Published 10/21/2024 Created 12/13/2024 Added 12/12/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue. 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-49855 CVE - 2024-49855 EulerOS-SA-2024-2983

Huawei EulerOS: CVE-2024-49851: 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: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure. 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-49851 CVE - 2024-49851 EulerOS-SA-2025-1159

Huawei EulerOS: CVE-2024-47749: 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: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE. 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-47749 CVE - 2024-47749 EulerOS-SA-2025-1159

Huawei EulerOS: CVE-2024-49925: 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: 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) 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-49925 CVE - 2024-49925 EulerOS-SA-2025-1159

Huawei EulerOS: CVE-2024-49934: 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: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS:00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: GW6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable. 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-49934 CVE - 2024-49934 EulerOS-SA-2025-1159

Amazon Linux AMI 2: CVE-2022-49017: Security patch for kernel (ALASKERNEL-5.10-2023-025) Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 10/21/2024 Created 01/23/2025 Added 01/22/2025 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: tipc: re-fetch skb cb after tipc_msg_validate As the call trace shows, the original skb was freed in tipc_msg_validate(), and dereferencing the old skb cb would cause an use-after-free crash. BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] Call Trace: <IRQ> tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc] ... Allocated by task 47078: kmem_cache_alloc_node+0x158/0x4d0 __alloc_skb+0x1c1/0x270 tipc_buf_acquire+0x1e/0xe0 [tipc] tipc_msg_create+0x33/0x1c0 [tipc] tipc_link_build_proto_msg+0x38a/0x2100 [tipc] tipc_link_timeout+0x8b8/0xef0 [tipc] tipc_node_timeout+0x2a1/0x960 [tipc] call_timer_fn+0x2d/0x1c0 ... Freed by task 47078: tipc_msg_validate+0x7b/0x440 [tipc] tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc] This patch fixes it by re-fetching the skb cb from the new allocated skb after calling tipc_msg_validate(). Solution(s) amazon-linux-ami-2-upgrade-bpftool amazon-linux-ami-2-upgrade-bpftool-debuginfo amazon-linux-ami-2-upgrade-kernel amazon-linux-ami-2-upgrade-kernel-debuginfo amazon-linux-ami-2-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-ami-2-upgrade-kernel-debuginfo-common-x86_64 amazon-linux-ami-2-upgrade-kernel-devel amazon-linux-ami-2-upgrade-kernel-headers amazon-linux-ami-2-upgrade-kernel-livepatch-5-10-162-141-675 amazon-linux-ami-2-upgrade-kernel-tools amazon-linux-ami-2-upgrade-kernel-tools-debuginfo amazon-linux-ami-2-upgrade-kernel-tools-devel amazon-linux-ami-2-upgrade-perf amazon-linux-ami-2-upgrade-perf-debuginfo amazon-linux-ami-2-upgrade-python-perf amazon-linux-ami-2-upgrade-python-perf-debuginfo References https://attackerkb.com/topics/cve-2022-49017 AL2/ALASKERNEL-5.10-2023-025 CVE - 2022-49017

Huawei EulerOS: CVE-2022-48946: 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: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication. 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-48946 CVE - 2022-48946 EulerOS-SA-2025-1192

Huawei EulerOS: CVE-2022-48953: 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: rtc: cmos: Fix event handler registration ordering issue Because acpi_install_fixed_event_handler() enables the event automatically on success, it is incorrect to call it before the handler routine passed to it is ready to handle events. Unfortunately, the rtc-cmos driver does exactly the incorrect thing by calling cmos_wake_setup(), which passes rtc_handler() to acpi_install_fixed_event_handler(), before cmos_do_probe(), because rtc_handler() uses dev_get_drvdata() to get to the cmos object pointer and the driver data pointer is only populated in cmos_do_probe(). This leads to a NULL pointer dereference in rtc_handler() on boot if the RTC fixed event happens to be active at the init time. To address this issue, change the initialization ordering of the driver so that cmos_wake_setup() is always called after a successful cmos_do_probe() call. While at it, change cmos_pnp_probe() to call cmos_do_probe() after the initial if () statement used for computing the IRQ argument to be passed to cmos_do_probe() which is cleaner than calling it in each branch of that if () (local variable "irq" can be of type int, because it is passed to that function as an argument of type int). Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number of systems, because previously it only affected systems with ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that commit. 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-48953 CVE - 2022-48953 EulerOS-SA-2025-1192

Huawei EulerOS: CVE-2022-48978: 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: HID: core: fix shift-out-of-bounds in hid_report_raw_event Syzbot reported shift-out-of-bounds in hid_report_raw_event. microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) > 32! (swapper/0) ====================================================================== UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20 shift exponent 127 is too large for 32-bit type 'int' CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322 snto32 drivers/hid/hid-core.c:1323 [inline] hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline] hid_process_report drivers/hid/hid-core.c:1665 [inline] hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998 hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066 hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284 __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671 dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988 call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers+0x76a/0x980 kernel/time/timer.c:1790 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803 __do_softirq+0x277/0x75b kernel/softirq.c:571 __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107 ====================================================================== If the size of the integer (unsigned n) is bigger than 32 in snto32(), shift exponent will be too large for 32-bit type 'int', resulting in a shift-out-of-bounds bug. Fix this by adding a check on the size of the integer (unsigned n) in snto32(). To add support for n greater than 32 bits, set n to 32, if n is greater than 32. 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-48978 CVE - 2022-48978 EulerOS-SA-2025-1192

Huawei EulerOS: CVE-2022-48961: 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: mdio: fix unbalanced fwnode reference count in mdio_device_release() There is warning report about of_node refcount leak while probing mdio device: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4 In of_mdiobus_register_device(), we increase fwnode refcount by fwnode_handle_get() before associating the of_node with mdio device, but it has never been decreased in normal path. Since that, in mdio_device_release(), it needs to call fwnode_handle_put() in addition instead of calling kfree() directly. After above, just calling mdio_device_free() in the error handle path of of_mdiobus_register_device() is enough to keep the refcount balanced. 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-48961 CVE - 2022-48961 EulerOS-SA-2025-1192

Huawei EulerOS: CVE-2022-49002: 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: iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init() for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the error path to avoid reference count leak. 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-49002 CVE - 2022-49002 EulerOS-SA-2025-1192

Huawei EulerOS: CVE-2024-47679: 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: 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) 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-47679 CVE - 2024-47679 EulerOS-SA-2025-1159

Huawei EulerOS: CVE-2024-47692: 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: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205]dump_stack+0x9a/0xd0 [ T1205]? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]__kasan_report.cold+0x34/0x84 [ T1205]? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]kasan_report+0x3a/0x50 [ T1205]nfs4_client_to_reclaim+0xe9/0x260 [ T1205]? nfsd4_release_lockowner+0x410/0x410 [ T1205]cld_pipe_downcall+0x5ca/0x760 [ T1205]? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205]? down_write_killable_nested+0x170/0x170 [ T1205]? avc_policy_seqno+0x28/0x40 [ T1205]? selinux_file_permission+0x1b4/0x1e0 [ T1205]rpc_pipe_write+0x84/0xb0 [ T1205]vfs_write+0x143/0x520 [ T1205]ksys_write+0xc9/0x170 [ T1205]? __ia32_sys_read+0x50/0x50 [ T1205]? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205]? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205]do_syscall_64+0x33/0x40 [ T1205]entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen. 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-47692 CVE - 2024-47692 EulerOS-SA-2025-1159

Debian: CVE-2024-49924: 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: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb| set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-49924 CVE - 2024-49924 DLA-4008-1

Debian: CVE-2024-49917: 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/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628) Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-49917 CVE - 2024-49917

Debian: CVE-2024-49909: 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: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-49909 CVE - 2024-49909

Debian: CVE-2024-49902: 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: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-49902 CVE - 2024-49902 DLA-4008-1

Debian: CVE-2024-49899: 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/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-49899 CVE - 2024-49899

Debian: CVE-2024-49898: 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: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-49898 CVE - 2024-49898

Debian: CVE-2024-49858: 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: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-49858 CVE - 2024-49858 DLA-4008-1

Huawei EulerOS: CVE-2024-49889: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 10/21/2024 Created 01/15/2025 Added 01/14/2025 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality. 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-49889 CVE - 2024-49889 EulerOS-SA-2025-1024