{"schema_version":"1.7.2","id":"OESA-2025-1110","modified":"2025-02-14T12:12:20Z","published":"2025-02-14T12:12:20Z","upstream":["CVE-2024-43098","CVE-2024-46832","CVE-2024-47141","CVE-2024-47408","CVE-2024-48873","CVE-2024-49568","CVE-2024-49571","CVE-2024-50051","CVE-2024-52332","CVE-2024-53056","CVE-2024-53096","CVE-2024-53105","CVE-2024-53208","CVE-2024-53222","CVE-2024-53690","CVE-2024-56369","CVE-2024-56610","CVE-2024-56617","CVE-2024-56686","CVE-2024-56690","CVE-2024-56698","CVE-2024-56715","CVE-2024-57791","CVE-2024-57841","CVE-2024-57882","CVE-2024-57888","CVE-2024-57916","CVE-2024-57925","CVE-2024-57932","CVE-2024-57933","CVE-2024-57939","CVE-2024-57940","CVE-2024-57947","CVE-2025-21645","CVE-2025-21649","CVE-2025-21684"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni3c: Use i3cdev-\u0026gt;desc-\u0026gt;info instead of calling i3c_device_get_info() to avoid deadlock\n\nA deadlock may happen since the i3c_master_register() acquires\n\u0026amp;i3cbus-\u0026gt;lock twice. See the log below.\nUse i3cdev-\u0026gt;desc-\u0026gt;info instead of calling i3c_device_info() to\navoid acquiring the lock twice.\n\nv2:\n  - Modified the title and commit message\n\n============================================\nWARNING: possible recursive locking detected\n6.11.0-mainline\n--------------------------------------------\ninit/1 is trying to acquire lock:\nf1ffff80a6a40dc0 (\u0026amp;i3cbus-\u0026gt;lock){++++}-{3:3}, at: i3c_bus_normaluse_lock\n\nbut task is already holding lock:\nf1ffff80a6a40dc0 (\u0026amp;i3cbus-\u0026gt;lock){++++}-{3:3}, at: i3c_master_register\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n       CPU0\n       ----\n  lock(\u0026amp;i3cbus-\u0026gt;lock);\n  lock(\u0026amp;i3cbus-\u0026gt;lock);\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n2 locks held by init/1:\n #0: fcffff809b6798f8 (\u0026amp;dev-\u0026gt;mutex){....}-{3:3}, at: __driver_attach\n #1: f1ffff80a6a40dc0 (\u0026amp;i3cbus-\u0026gt;lock){++++}-{3:3}, at: i3c_master_register\n\nstack backtrace:\nCPU: 6 UID: 0 PID: 1 Comm: init\nCall trace:\n dump_backtrace+0xfc/0x17c\n show_stack+0x18/0x28\n dump_stack_lvl+0x40/0xc0\n dump_stack+0x18/0x24\n print_deadlock_bug+0x388/0x390\n __lock_acquire+0x18bc/0x32ec\n lock_acquire+0x134/0x2b0\n down_read+0x50/0x19c\n i3c_bus_normaluse_lock+0x14/0x24\n i3c_device_get_info+0x24/0x58\n i3c_device_uevent+0x34/0xa4\n dev_uevent+0x310/0x384\n kobject_uevent_env+0x244/0x414\n kobject_uevent+0x14/0x20\n device_add+0x278/0x460\n device_register+0x20/0x34\n i3c_master_register_new_i3c_devs+0x78/0x154\n i3c_master_register+0x6a0/0x6d4\n mtk_i3c_master_probe+0x3b8/0x4d8\n platform_probe+0xa0/0xe0\n really_probe+0x114/0x454\n __driver_probe_device+0xa0/0x15c\n driver_probe_device+0x3c/0x1ac\n __driver_attach+0xc4/0x1f0\n bus_for_each_dev+0x104/0x160\n driver_attach+0x24/0x34\n bus_add_driver+0x14c/0x294\n driver_register+0x68/0x104\n __platform_driver_register+0x20/0x30\n init_module+0x20/0xfe4\n do_one_initcall+0x184/0x464\n do_init_module+0x58/0x1ec\n load_module+0xefc/0x10c8\n __arm64_sys_finit_module+0x238/0x33c\n invoke_syscall+0x58/0x10c\n el0_svc_common+0xa8/0xdc\n do_el0_svc+0x1c/0x28\n el0_svc+0x50/0xac\n el0t_64_sync_handler+0x70/0xbc\n el0t_64_sync+0x1a8/0x1ac(CVE-2024-43098)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: cevt-r4k: Don\u0026apos;t call get_c0_compare_int if timer irq is installed\n\nThis avoids warning:\n\n[    0.118053] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283\n\nCaused by get_c0_compare_int on secondary CPU.\n\nWe also skipped saving IRQ number to struct clock_event_device *cd as\nit\u0026apos;s never used by clockevent core, as per comments it\u0026apos;s only meant\nfor \u0026quot;non CPU local devices\u0026quot;.(CVE-2024-46832)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinmux: Use sequential access to access desc-\u0026gt;pinmux data\n\nWhen two client of the same gpio call pinctrl_select_state() for the\nsame functionality, we are seeing NULL pointer issue while accessing\ndesc-\u0026gt;mux_owner.\n\nLet\u0026apos;s say two processes A, B executing in pin_request() for the same pin\nand process A updates the desc-\u0026gt;mux_usecount but not yet updated the\ndesc-\u0026gt;mux_owner while process B see the desc-\u0026gt;mux_usecount which got\nupdated by A path and further executes strcmp and while accessing\ndesc-\u0026gt;mux_owner it crashes with NULL pointer.\n\nSerialize the access to mux related setting with a mutex lock.\n\n\tcpu0 (process A)\t\t\tcpu1(process B)\n\npinctrl_select_state() {\t\t  pinctrl_select_state() {\n  pin_request() {\t\t\t\tpin_request() {\n  ...\n\t\t\t\t\t\t ....\n    } else {\n         desc-\u0026gt;mux_usecount++;\n    \t\t\t\t\t\tdesc-\u0026gt;mux_usecount \u0026amp;\u0026amp; strcmp(desc-\u0026gt;mux_owner, owner)) {\n\n         if (desc-\u0026gt;mux_usecount \u0026gt; 1)\n               return 0;\n         desc-\u0026gt;mux_owner = owner;\n\n  }\t\t\t\t\t\t}(CVE-2024-47141)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: check smcd_v2_ext_offset when receiving proposal msg\n\nWhen receiving proposal msg in server, the field smcd_v2_ext_offset in\nproposal msg is from the remote client and can not be fully trusted.\nOnce the value of smcd_v2_ext_offset exceed the max value, there has\nthe chance to access wrong address, and crash may happen.\n\nThis patch checks the value of smcd_v2_ext_offset before using it.(CVE-2024-47408)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: check return value of ieee80211_probereq_get() for RNR\n\nThe return value of ieee80211_probereq_get() might be NULL, so check it\nbefore using to avoid NULL pointer access.\n\nAddresses-Coverity-ID: 1529805 (\u0026quot;Dereference null return value\u0026quot;)(CVE-2024-48873)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msg\n\nWhen receiving proposal msg in server, the fields v2_ext_offset/\neid_cnt/ism_gid_cnt in proposal msg are from the remote client\nand can not be fully trusted. Especially the field v2_ext_offset,\nonce exceed the max value, there has the chance to access wrong\naddress, and crash may happen.\n\nThis patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cnt\nbefore using them.(CVE-2024-49568)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msg\n\nWhen receiving proposal msg in server, the field iparea_offset\nand the field ipv6_prefixes_cnt in proposal msg are from the\nremote client and can not be fully trusted. Especially the\nfield iparea_offset, once exceed the max value, there has the\nchance to access wrong address, and crash may happen.\n\nThis patch checks iparea_offset and ipv6_prefixes_cnt before using them.(CVE-2024-49571)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: mpc52xx: Add cancel_work_sync before module remove\n\nIf we remove the module which will call mpc52xx_spi_remove\nit will free \u0026apos;ms\u0026apos; through spi_unregister_controller.\nwhile the work ms-\u0026gt;work will be used. The sequence of operations\nthat may lead to a UAF bug.\n\nFix it by ensuring that the work is canceled before proceeding with\nthe cleanup in mpc52xx_spi_remove.(CVE-2024-50051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nigb: Fix potential invalid memory access in igb_init_module()\n\nThe pci_register_driver() can fail and when this happened, the dca_notifier\nneeds to be unregistered, otherwise the dca_notifier can be called when\nigb fails to install, resulting to invalid memory access.(CVE-2024-52332)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()\n\nIn mtk_crtc_create(), if the call to mbox_request_channel() fails then we\nset the \u0026quot;mtk_crtc-\u0026gt;cmdq_client.chan\u0026quot; pointer to NULL.  In that situation,\nwe do not call cmdq_pkt_create().\n\nDuring the cleanup, we need to check if the \u0026quot;mtk_crtc-\u0026gt;cmdq_client.chan\u0026quot;\nis NULL first before calling cmdq_pkt_destroy().  Calling\ncmdq_pkt_destroy() is unnecessary if we didn\u0026apos;t call cmdq_pkt_create() and\nit will result in a NULL pointer dereference.(CVE-2024-53056)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: resolve faulty mmap_region() error path behaviour\n\nThe mmap_region() function is somewhat terrifying, with spaghetti-like\ncontrol flow and numerous means by which issues can arise and incomplete\nstate, memory leaks and other unpleasantness can occur.\n\nA large amount of the complexity arises from trying to handle errors late\nin the process of mapping a VMA, which forms the basis of recently\nobserved issues with resource leaks and observable inconsistent state.\n\nTaking advantage of previous patches in this series we move a number of\nchecks earlier in the code, simplifying things by moving the core of the\nlogic into a static internal function __mmap_region().\n\nDoing this allows us to perform a number of checks up front before we do\nany real work, and allows us to unwind the writable unmap check\nunconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE\nvalidation unconditionally also.\n\nWe move a number of things here:\n\n1. We preallocate memory for the iterator before we call the file-backed\n   memory hook, allowing us to exit early and avoid having to perform\n   complicated and error-prone close/free logic. We carefully free\n   iterator state on both success and error paths.\n\n2. The enclosing mmap_region() function handles the mapping_map_writable()\n   logic early. Previously the logic had the mapping_map_writable() at the\n   point of mapping a newly allocated file-backed VMA, and a matching\n   mapping_unmap_writable() on success and error paths.\n\n   We now do this unconditionally if this is a file-backed, shared writable\n   mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however\n   doing so does not invalidate the seal check we just performed, and we in\n   any case always decrement the counter in the wrapper.\n\n   We perform a debug assert to ensure a driver does not attempt to do the\n   opposite.\n\n3. We also move arch_validate_flags() up into the mmap_region()\n   function. This is only relevant on arm64 and sparc64, and the check is\n   only meaningful for SPARC with ADI enabled. We explicitly add a warning\n   for this arch if a driver invalidates this check, though the code ought\n   eventually to be fixed to eliminate the need for this.\n\nWith all of these measures in place, we no longer need to explicitly close\nthe VMA on error paths, as we place all checks which might fail prior to a\ncall to any driver mmap hook.\n\nThis eliminates an entire class of errors, makes the code easier to reason\nabout and more robust.(CVE-2024-53096)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: page_alloc: move mlocked flag clearance into free_pages_prepare()\n\nSyzbot reported a bad page state problem caused by a page being freed\nusing free_page() still having a mlocked flag at free_pages_prepare()\nstage:\n\n  BUG: Bad page state in process syz.5.504  pfn:61f45\n  page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45\n  flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff)\n  raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000\n  raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n  page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set\n  page_owner tracks the page as allocated\n  page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394\n   set_page_owner include/linux/page_owner.h:32 [inline]\n   post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537\n   prep_new_page mm/page_alloc.c:1545 [inline]\n   get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457\n   __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733\n   alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265\n   kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99\n   kvm_create_vm virt/kvm/kvm_main.c:1235 [inline]\n   kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline]\n   kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530\n   __do_compat_sys_ioctl fs/ioctl.c:1007 [inline]\n   __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950\n   do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]\n   __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386\n   do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411\n   entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n  page last free pid 8399 tgid 8399 stack trace:\n   reset_page_owner include/linux/page_owner.h:25 [inline]\n   free_pages_prepare mm/page_alloc.c:1108 [inline]\n   free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686\n   folios_put_refs+0x76c/0x860 mm/swap.c:1007\n   free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335\n   __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline]\n   tlb_batch_pages_flush mm/mmu_gather.c:149 [inline]\n   tlb_flush_mmu_free mm/mmu_gather.c:366 [inline]\n   tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373\n   tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465\n   exit_mmap+0x496/0xc40 mm/mmap.c:1926\n   __mmput+0x115/0x390 kernel/fork.c:1348\n   exit_mm+0x220/0x310 kernel/exit.c:571\n   do_exit+0x9b2/0x28e0 kernel/exit.c:926\n   do_group_exit+0x207/0x2c0 kernel/exit.c:1088\n   __do_sys_exit_group kernel/exit.c:1099 [inline]\n   __se_sys_exit_group kernel/exit.c:1097 [inline]\n   __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097\n   x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232\n   do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n  Modules linked in:\n  CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   __dump_stack lib/dump_stack.c:94 [inline]\n   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n   bad_page+0x176/0x1d0 mm/page_alloc.c:501\n   free_page_is_bad mm/page_alloc.c:918 [inline]\n   free_pages_prepare mm/page_alloc.c:1100 [inline]\n   free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638\n   kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline]\n   kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386\n   kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143\n   __fput+0x23f/0x880 fs/file_table.c:431\n   task_work_run+0x24f/0x310 kernel/task_work.c:239\n   exit_task_work include/linux/task_work.h:43 [inline]\n   do_exit+0xa2f/0x28e0 kernel/exit.c:939\n   do_group_exit+0x207/0x2c0 kernel/exit.c:1088\n   __do_sys_exit_group kernel/exit.c:1099 [in\n---truncated---(CVE-2024-53105)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix slab-use-after-free Read in set_powered_sync\n\nThis fixes the following crash:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in set_powered_sync+0x3a/0xc0 net/bluetooth/mgmt.c:1353\nRead of size 8 at addr ffff888029b4dd18 by task kworker/u9:0/54\n\nCPU: 1 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-01155-gf723224742fc #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nWorkqueue: hci0 hci_cmd_sync_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:93 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\nq kasan_report+0x143/0x180 mm/kasan/report.c:601\n set_powered_sync+0x3a/0xc0 net/bluetooth/mgmt.c:1353\n hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:328\n process_one_work kernel/workqueue.c:3231 [inline]\n process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312\n worker_thread+0x86d/0xd10 kernel/workqueue.c:3389\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 5247:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:370 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387\n kasan_kmalloc include/linux/kasan.h:211 [inline]\n __kmalloc_cache_noprof+0x19c/0x2c0 mm/slub.c:4193\n kmalloc_noprof include/linux/slab.h:681 [inline]\n kzalloc_noprof include/linux/slab.h:807 [inline]\n mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269\n mgmt_pending_add+0x36/0x120 net/bluetooth/mgmt_util.c:296\n set_powered+0x3cd/0x5e0 net/bluetooth/mgmt.c:1394\n hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712\n hci_sock_sendmsg+0x7b8/0x11c0 net/bluetooth/hci_sock.c:1832\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x221/0x270 net/socket.c:745\n sock_write_iter+0x2dd/0x400 net/socket.c:1160\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0xa72/0xc90 fs/read_write.c:590\n ksys_write+0x1a0/0x2c0 fs/read_write.c:643\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 5246:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579\n poison_slab_object+0xe0/0x150 mm/kasan/common.c:240\n __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256\n kasan_slab_free include/linux/kasan.h:184 [inline]\n slab_free_hook mm/slub.c:2256 [inline]\n slab_free mm/slub.c:4477 [inline]\n kfree+0x149/0x360 mm/slub.c:4598\n settings_rsp+0x2bc/0x390 net/bluetooth/mgmt.c:1443\n mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259\n __mgmt_power_off+0x112/0x420 net/bluetooth/mgmt.c:9455\n hci_dev_close_sync+0x665/0x11a0 net/bluetooth/hci_sync.c:5191\n hci_dev_do_close net/bluetooth/hci_core.c:483 [inline]\n hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508\n sock_do_ioctl+0x158/0x460 net/socket.c:1222\n sock_ioctl+0x629/0x8e0 net/socket.c:1341\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83gv\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-53208)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nzram: fix NULL pointer in comp_algorithm_show()\n\nLTP reported a NULL pointer dereference as followed:\n\n CPU: 7 UID: 0 PID: 5995 Comm: cat Kdump: loaded Not tainted 6.12.0-rc6+ #3\n Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __pi_strcmp+0x24/0x140\n lr : zcomp_available_show+0x60/0x100 [zram]\n sp : ffff800088b93b90\n x29: ffff800088b93b90 x28: 0000000000000001 x27: 0000000000400cc0\n x26: 0000000000000ffe x25: ffff80007b3e2388 x24: 0000000000000000\n x23: ffff80007b3e2390 x22: ffff0004041a9000 x21: ffff80007b3e2900\n x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: ffff80007b3e2900 x9 : ffff80007b3cb280\n x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : 0000000000000040 x4 : 0000000000000000 x3 : 00656c722d6f7a6c\n x2 : 0000000000000000 x1 : ffff80007b3e2900 x0 : 0000000000000000\n Call trace:\n  __pi_strcmp+0x24/0x140\n  comp_algorithm_show+0x40/0x70 [zram]\n  dev_attr_show+0x28/0x80\n  sysfs_kf_seq_show+0x90/0x140\n  kernfs_seq_show+0x34/0x48\n  seq_read_iter+0x1d4/0x4e8\n  kernfs_fop_read_iter+0x40/0x58\n  new_sync_read+0x9c/0x168\n  vfs_read+0x1a8/0x1f8\n  ksys_read+0x74/0x108\n  __arm64_sys_read+0x24/0x38\n  invoke_syscall+0x50/0x120\n  el0_svc_common.constprop.0+0xc8/0xf0\n  do_el0_svc+0x24/0x38\n  el0_svc+0x38/0x138\n  el0t_64_sync_handler+0xc0/0xc8\n  el0t_64_sync+0x188/0x190\n\nThe zram-\u0026gt;comp_algs[ZRAM_PRIMARY_COMP] can be NULL in zram_add() if\ncomp_algorithm_set() has not been called.  User can access the zram device\nby sysfs after device_add_disk(), so there is a time window to trigger the\nNULL pointer dereference.  Move it ahead device_add_disk() to make sure\nwhen user can access the zram device, it is ready.  comp_algorithm_set()\nis protected by zram-\u0026gt;init_lock in other places and no such problem.(CVE-2024-53222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: prevent use of deleted inode\n\nsyzbot reported a WARNING in nilfs_rmdir. [1]\n\nBecause the inode bitmap is corrupted, an inode with an inode number that\nshould exist as a \u0026quot;.nilfs\u0026quot; file was reassigned by nilfs_mkdir for \u0026quot;file0\u0026quot;,\ncausing an inode duplication during execution.  And this causes an\nunderflow of i_nlink in rmdir operations.\n\nThe inode is used twice by the same task to unmount and remove directories\n\u0026quot;.nilfs\u0026quot; and \u0026quot;file0\u0026quot;, it trigger warning in nilfs_rmdir.\n\nAvoid to this issue, check i_nlink in nilfs_iget(), if it is 0, it means\nthat this inode has been deleted, and iput is executed to reclaim it.\n\n[1]\nWARNING: CPU: 1 PID: 5824 at fs/inode.c:407 drop_nlink+0xc4/0x110 fs/inode.c:407\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n nilfs_rmdir+0x1b0/0x250 fs/nilfs2/namei.c:342\n vfs_rmdir+0x3a3/0x510 fs/namei.c:4394\n do_rmdir+0x3b5/0x580 fs/namei.c:4453\n __do_sys_rmdir fs/namei.c:4472 [inline]\n __se_sys_rmdir fs/namei.c:4470 [inline]\n __x64_sys_rmdir+0x47/0x50 fs/namei.c:4470\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-53690)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/modes: Avoid divide by zero harder in drm_mode_vrefresh()\n\ndrm_mode_vrefresh() is trying to avoid divide by zero\nby checking whether htotal or vtotal are zero. But we may\nstill end up with a div-by-zero of vtotal*htotal*...(CVE-2024-56369)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkcsan: Turn report_filterlist_lock into a raw_spinlock\n\nRan Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see\nsplats like:\n\n| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1\n| preempt_count: 10002, expected: 0\n| RCU nest depth: 0, expected: 0\n| no locks held by swapper/1/0.\n| irq event stamp: 156674\n| hardirqs last  enabled at (156673): [\u0026lt;ffffffff81130bd9\u0026gt;] do_idle+0x1f9/0x240\n| hardirqs last disabled at (156674): [\u0026lt;ffffffff82254f84\u0026gt;] sysvec_apic_timer_interrupt+0x14/0xc0\n| softirqs last  enabled at (0): [\u0026lt;ffffffff81099f47\u0026gt;] copy_process+0xfc7/0x4b60\n| softirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n| Preemption disabled at:\n| [\u0026lt;ffffffff814a3e2a\u0026gt;] paint_ptr+0x2a/0x90\n| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3\n| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014\n| Call Trace:\n|  \u0026lt;IRQ\u0026gt;\n|  dump_stack_lvl+0x7e/0xc0\n|  dump_stack+0x1d/0x30\n|  __might_resched+0x1a2/0x270\n|  rt_spin_lock+0x68/0x170\n|  kcsan_skip_report_debugfs+0x43/0xe0\n|  print_report+0xb5/0x590\n|  kcsan_report_known_origin+0x1b1/0x1d0\n|  kcsan_setup_watchpoint+0x348/0x650\n|  __tsan_unaligned_write1+0x16d/0x1d0\n|  hrtimer_interrupt+0x3d6/0x430\n|  __sysvec_apic_timer_interrupt+0xe8/0x3a0\n|  sysvec_apic_timer_interrupt+0x97/0xc0\n|  \u0026lt;/IRQ\u0026gt;\n\nOn a detected data race, KCSAN\u0026apos;s reporting logic checks if it should\nfilter the report. That list is protected by the report_filterlist_lock\n*non-raw* spinlock which may sleep on RT kernels.\n\nSince KCSAN may report data races in any context, convert it to a\nraw_spinlock.\n\nThis requires being careful about when to allocate memory for the filter\nlist itself which can be done via KCSAN\u0026apos;s debugfs interface. Concurrent\nmodification of the filter list via debugfs should be rare: the chosen\nstrategy is to optimistically pre-allocate memory before the critical\nsection and discard if unused.(CVE-2024-56610)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncacheinfo: Allocate memory during CPU hotplug if not done from the primary CPU\n\nCommit\n\n  5944ce092b97 (\u0026quot;arch_topology: Build cacheinfo from primary CPU\u0026quot;)\n\nadds functionality that architectures can use to optionally allocate and\nbuild cacheinfo early during boot. Commit\n\n  6539cffa9495 (\u0026quot;cacheinfo: Add arch specific early level initializer\u0026quot;)\n\nlets secondary CPUs correct (and reallocate memory) cacheinfo data if\nneeded.\n\nIf the early build functionality is not used and cacheinfo does not need\ncorrection, memory for cacheinfo is never allocated. x86 does not use\nthe early build functionality. Consequently, during the cacheinfo CPU\nhotplug callback, last_level_cache_is_valid() attempts to dereference\na NULL pointer:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000100\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not present page\n  PGD 0 P4D 0\n  Oops: 0000 [#1] PREEPMT SMP NOPTI\n  CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1\n  RIP: 0010: last_level_cache_is_valid+0x95/0xe0a\n\nAllocate memory for cacheinfo during the cacheinfo CPU hotplug callback\nif not done earlier.\n\nMoreover, before determining the validity of the last-level cache info,\nensure that it has been allocated. Simply checking for non-zero\ncache_leaves() is not sufficient, as some architectures (e.g., Intel\nprocessors) have non-zero cache_leaves() before allocation.\n\nDereferencing NULL cacheinfo can occur in update_per_cpu_data_slice_size().\nThis function iterates over all online CPUs. However, a CPU may have come\nonline recently, but its cacheinfo may not have been allocated yet.\n\nWhile here, remove an unnecessary indentation in allocate_cache_info().\n\n  [ bp: Massage. ](CVE-2024-56617)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-56686)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY\n\nSince commit 8f4f68e788c3 (\u0026quot;crypto: pcrypt - Fix hungtask for\nPADATA_RESET\u0026quot;), the pcrypt encryption and decryption operations return\n-EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is\ngenerated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns\n-EAGAIN, the unnecessary panic will occur when panic_on_warn set 1.\nFix this issue by calling crypto layer directly without parallelization\nin that case.(CVE-2024-56690)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: gadget: Fix looping of queued SG entries\n\nThe dwc3_request-\u0026gt;num_queued_sgs is decremented on completion. If a\npartially completed request is handled, then the\ndwc3_request-\u0026gt;num_queued_sgs no longer reflects the total number of\nnum_queued_sgs (it would be cleared).\n\nCorrectly check the number of request SG entries remained to be prepare\nand queued. Failure to do this may cause null pointer dereference when\naccessing non-existent SG entry.(CVE-2024-56698)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nionic: Fix netdev notifier unregister on failure\n\nIf register_netdev() fails, then the driver leaks the netdev notifier.\nFix this by calling ionic_lif_unregister() on register_netdev()\nfailure. This will also call ionic_lif_unregister_phc() if it has\nalready been registered.(CVE-2024-56715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: check return value of sock_recvmsg when draining clc data\n\nWhen receiving clc msg, the field length in smc_clc_msg_hdr indicates the\nlength of msg should be received from network and the value should not be\nfully trusted as it is from the network. Once the value of length exceeds\nthe value of buflen in function smc_clc_wait_msg it may run into deadloop\nwhen trying to drain the remaining data exceeding buflen.\n\nThis patch checks the return value of sock_recvmsg when draining data in\ncase of deadloop in draining.(CVE-2024-57791)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix memory leak in tcp_conn_request()\n\nIf inet_csk_reqsk_queue_hash_add() return false, tcp_conn_request() will\nreturn without free the dst memory, which allocated in af_ops-\u0026gt;route_req.\n\nHere is the kmemleak stack:\n\nunreferenced object 0xffff8881198631c0 (size 240):\n  comm \u0026quot;softirq\u0026quot;, pid 0, jiffies 4299266571 (age 1802.392s)\n  hex dump (first 32 bytes):\n    00 10 9b 03 81 88 ff ff 80 98 da bc ff ff ff ff  ................\n    81 55 18 bb ff ff ff ff 00 00 00 00 00 00 00 00  .U..............\n  backtrace:\n    [\u0026lt;ffffffffb93e8d4c\u0026gt;] kmem_cache_alloc+0x60c/0xa80\n    [\u0026lt;ffffffffba11b4c5\u0026gt;] dst_alloc+0x55/0x250\n    [\u0026lt;ffffffffba227bf6\u0026gt;] rt_dst_alloc+0x46/0x1d0\n    [\u0026lt;ffffffffba23050a\u0026gt;] __mkroute_output+0x29a/0xa50\n    [\u0026lt;ffffffffba23456b\u0026gt;] ip_route_output_key_hash+0x10b/0x240\n    [\u0026lt;ffffffffba2346bd\u0026gt;] ip_route_output_flow+0x1d/0x90\n    [\u0026lt;ffffffffba254855\u0026gt;] inet_csk_route_req+0x2c5/0x500\n    [\u0026lt;ffffffffba26b331\u0026gt;] tcp_conn_request+0x691/0x12c0\n    [\u0026lt;ffffffffba27bd08\u0026gt;] tcp_rcv_state_process+0x3c8/0x11b0\n    [\u0026lt;ffffffffba2965c6\u0026gt;] tcp_v4_do_rcv+0x156/0x3b0\n    [\u0026lt;ffffffffba299c98\u0026gt;] tcp_v4_rcv+0x1cf8/0x1d80\n    [\u0026lt;ffffffffba239656\u0026gt;] ip_protocol_deliver_rcu+0xf6/0x360\n    [\u0026lt;ffffffffba2399a6\u0026gt;] ip_local_deliver_finish+0xe6/0x1e0\n    [\u0026lt;ffffffffba239b8e\u0026gt;] ip_local_deliver+0xee/0x360\n    [\u0026lt;ffffffffba239ead\u0026gt;] ip_rcv+0xad/0x2f0\n    [\u0026lt;ffffffffba110943\u0026gt;] __netif_receive_skb_one_core+0x123/0x140\n\nCall dst_release() to free the dst memory when\ninet_csk_reqsk_queue_hash_add() return false in tcp_conn_request().(CVE-2024-57841)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix TCP options overflow.\n\nSyzbot reported the following splat:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 1 UID: 0 PID: 5836 Comm: sshd Not tainted 6.13.0-rc3-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024\nRIP: 0010:_compound_head include/linux/page-flags.h:242 [inline]\nRIP: 0010:put_page+0x23/0x260 include/linux/mm.h:1552\nCode: 90 90 90 90 90 90 90 55 41 57 41 56 53 49 89 fe 48 bd 00 00 00 00 00 fc ff df e8 f8 5e 12 f8 49 8d 5e 08 48 89 d8 48 c1 e8 03 \u0026lt;80\u0026gt; 3c 28 00 74 08 48 89 df e8 8f c7 78 f8 48 8b 1b 48 89 de 48 83\nRSP: 0000:ffffc90003916c90 EFLAGS: 00010202\nRAX: 0000000000000001 RBX: 0000000000000008 RCX: ffff888030458000\nRDX: 0000000000000100 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: dffffc0000000000 R08: ffffffff898ca81d R09: 1ffff110054414ac\nR10: dffffc0000000000 R11: ffffed10054414ad R12: 0000000000000007\nR13: ffff88802a20a542 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007f34f496e800(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f9d6ec9ec28 CR3: 000000004d260000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n skb_page_unref include/linux/skbuff_ref.h:43 [inline]\n __skb_frag_unref include/linux/skbuff_ref.h:56 [inline]\n skb_release_data+0x483/0x8a0 net/core/skbuff.c:1119\n skb_release_all net/core/skbuff.c:1190 [inline]\n __kfree_skb+0x55/0x70 net/core/skbuff.c:1204\n tcp_clean_rtx_queue net/ipv4/tcp_input.c:3436 [inline]\n tcp_ack+0x2442/0x6bc0 net/ipv4/tcp_input.c:4032\n tcp_rcv_state_process+0x8eb/0x44e0 net/ipv4/tcp_input.c:6805\n tcp_v4_do_rcv+0x77d/0xc70 net/ipv4/tcp_ipv4.c:1939\n tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2351\n ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233\n NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314\n NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314\n __netif_receive_skb_one_core net/core/dev.c:5672 [inline]\n __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5785\n process_backlog+0x662/0x15b0 net/core/dev.c:6117\n __napi_poll+0xcb/0x490 net/core/dev.c:6883\n napi_poll net/core/dev.c:6952 [inline]\n net_rx_action+0x89b/0x1240 net/core/dev.c:7074\n handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561\n __do_softirq kernel/softirq.c:595 [inline]\n invoke_softirq kernel/softirq.c:435 [inline]\n __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:678\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]\n sysvec_apic_timer_interrupt+0x57/0xc0 arch/x86/kernel/apic/apic.c:1049\n asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702\nRIP: 0033:0x7f34f4519ad5\nCode: 85 d2 74 0d 0f 10 02 48 8d 54 24 20 0f 11 44 24 20 64 8b 04 25 18 00 00 00 85 c0 75 27 41 b8 08 00 00 00 b8 0f 01 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 76 75 48 8b 15 24 73 0d 00 f7 d8 64 89 02 48 83\nRSP: 002b:00007ffec5b32ce0 EFLAGS: 00000246\nRAX: 0000000000000001 RBX: 00000000000668a0 RCX: 00007f34f4519ad5\nRDX: 00007ffec5b32d00 RSI: 0000000000000004 RDI: 0000564f4bc6cae0\nRBP: 0000564f4bc6b5a0 R08: 0000000000000008 R09: 0000000000000000\nR10: 00007ffec5b32de8 R11: 0000000000000246 R12: 0000564f48ea8aa4\nR13: 0000000000000001 R14: 0000564f48ea93e8 R15: 00007ffec5b32d68\n \u0026lt;/TASK\u0026gt;\n\nEric noted a probable shinfo-\u0026gt;nr_frags corruption, which indeed\noccurs.\n\nThe root cause is a buggy MPTCP option len computation in some\ncircumstances: the ADD_ADDR option should be mutually exclusive\nwith DSS since the blamed commit.\n\nStill, mptcp_established_options_add_addr() tries to set the\nrelevant info in mptcp_out_options, if \n---truncated---(CVE-2024-57882)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nworkqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM worker\n\nAfter commit\n746ae46c1113 (\u0026quot;drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM\u0026quot;)\namdgpu started seeing the following warning:\n\n [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu]\n...\n [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched]\n...\n [ ] Call Trace:\n [ ]  \u0026lt;TASK\u0026gt;\n...\n [ ]  ? check_flush_dependency+0xf5/0x110\n...\n [ ]  cancel_delayed_work_sync+0x6e/0x80\n [ ]  amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu]\n [ ]  amdgpu_ring_alloc+0x40/0x50 [amdgpu]\n [ ]  amdgpu_ib_schedule+0xf4/0x810 [amdgpu]\n [ ]  ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched]\n [ ]  amdgpu_job_run+0xaa/0x1f0 [amdgpu]\n [ ]  drm_sched_run_job_work+0x257/0x430 [gpu_sched]\n [ ]  process_one_work+0x217/0x720\n...\n [ ]  \u0026lt;/TASK\u0026gt;\n\nThe intent of the verifcation done in check_flush_depedency is to ensure\nforward progress during memory reclaim, by flagging cases when either a\nmemory reclaim process, or a memory reclaim work item is flushed from a\ncontext not marked as memory reclaim safe.\n\nThis is correct when flushing, but when called from the\ncancel(_delayed)_work_sync() paths it is a false positive because work is\neither already running, or will not be running at all. Therefore\ncancelling it is safe and we can relax the warning criteria by letting the\nhelper know of the calling context.\n\nReferences: 746ae46c1113 (\u0026quot;drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM\u0026quot;)(CVE-2024-57888)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmisc: microchip: pci1xxxx: Resolve kernel panic during GPIO IRQ handling\n\nResolve kernel panic caused by improper handling of IRQs while\naccessing GPIO values. This is done by replacing generic_handle_irq with\nhandle_nested_irq.(CVE-2024-57916)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix a missing return value check bug\n\nIn the smb2_send_interim_resp(), if ksmbd_alloc_work_struct()\nfails to allocate a node, it returns a NULL pointer to the\nin_work pointer. This can lead to an illegal memory write of\nin_work-\u0026gt;response_buf when allocate_interim_rsp_buf() attempts\nto perform a kzalloc() on it.\n\nTo address this issue, incorporating a check for the return\nvalue of ksmbd_alloc_work_struct() ensures that the function\nreturns immediately upon allocation failure, thereby preventing\nthe aforementioned illegal memory access.(CVE-2024-57925)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngve: guard XDP xmit NDO on existence of xdp queues\n\nIn GVE, dedicated XDP queues only exist when an XDP program is installed\nand the interface is up. As such, the NDO XDP XMIT callback should\nreturn early if either of these conditions are false.\n\nIn the case of no loaded XDP program, priv-\u0026gt;num_xdp_queues=0 which can\ncause a divide-by-zero error, and in the case of interface down,\nnum_xdp_queues remains untouched to persist XDP queue count for the next\ninterface up, but the TX pointer itself would be NULL.\n\nThe XDP xmit callback also needs to synchronize with a device\ntransitioning from open to close. This synchronization will happen via\nthe GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call,\nwhich waits for any RCU critical sections at call-time to complete.(CVE-2024-57932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngve: guard XSK operations on the existence of queues\n\nThis patch predicates the enabling and disabling of XSK pools on the\nexistence of queues. As it stands, if the interface is down, disabling\nor enabling XSK pools would result in a crash, as the RX queue pointer\nwould be NULL. XSK pool registration will occur as part of the next\ninterface up.\n\nSimilarly, xsk_wakeup needs be guarded against queues disappearing\nwhile the function is executing, so a check against the\nGVE_PRIV_FLAGS_NAPI_ENABLED flag is added to synchronize with the\ndisabling of the bit and the synchronize_net() in gve_turndown.(CVE-2024-57933)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: Fix sleeping in invalid context in die()\n\ndie() can be called in exception handler, and therefore cannot sleep.\nHowever, die() takes spinlock_t which can sleep with PREEMPT_RT enabled.\nThat causes the following warning:\n\nBUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\nin_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 285, name: mutex\npreempt_count: 110001, expected: 0\nRCU nest depth: 0, expected: 0\nCPU: 0 UID: 0 PID: 285 Comm: mutex Not tainted 6.12.0-rc7-00022-ge19049cf7d56-dirty #234\nHardware name: riscv-virtio,qemu (DT)\nCall Trace:\n    dump_backtrace+0x1c/0x24\n    show_stack+0x2c/0x38\n    dump_stack_lvl+0x5a/0x72\n    dump_stack+0x14/0x1c\n    __might_resched+0x130/0x13a\n    rt_spin_lock+0x2a/0x5c\n    die+0x24/0x112\n    do_trap_insn_illegal+0xa0/0xea\n    _new_vmalloc_restore_context_a0+0xcc/0xd8\nOops - illegal instruction [#1]\n\nSwitch to use raw_spinlock_t, which does not sleep even with PREEMPT_RT\nenabled.(CVE-2024-57939)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nexfat: fix the infinite loop in exfat_readdir()\n\nIf the file system is corrupted so that a cluster is linked to\nitself in the cluster chain, and there is an unused directory\nentry in the cluster, \u0026apos;dentry\u0026apos; will not be incremented, causing\ncondition \u0026apos;dentry \u0026lt; max_dentries\u0026apos; unable to prevent an infinite\nloop.\n\nThis infinite loop causes s_lock not to be released, and other\ntasks will hang, such as exfat_sync_fs().\n\nThis commit stops traversing the cluster chain when there is unused\ndirectory entry in the cluster to avoid this infinite loop.(CVE-2024-57940)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_set_pipapo: fix initial map fill\n\nThe initial buffer has to be inited to all-ones, but it must restrict\nit to the size of the first field, not the total field size.\n\nAfter each round in the map search step, the result and the fill map\nare swapped, so if we have a set where f-\u0026gt;bsize of the first element\nis smaller than m-\u0026gt;bsize_max, those one-bits are leaked into future\nrounds result map.\n\nThis makes pipapo find an incorrect matching results for sets where\nfirst field size is not the largest.\n\nFollowup patch adds a test case to nft_concat_range.sh selftest script.\n\nThanks to Stefano Brivio for pointing out that we need to zero out\nthe remainder explicitly, only correcting memset() argument isn\u0026apos;t enough.(CVE-2024-57947)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it\n\nWakeup for IRQ1 should be disabled only in cases where i8042 had\nactually enabled it, otherwise \u0026quot;wake_depth\u0026quot; for this IRQ will try to\ndrop below zero and there will be an unpleasant WARN() logged:\n\nkernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug\nkernel: ------------[ cut here ]------------\nkernel: Unbalanced IRQ 1 wake disable\nkernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irq_set_irq_wake+0x147/0x1a0\n\nThe PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_ops\nwhich sets amd_pmc_suspend_handler() to the .suspend, .freeze, and\n.poweroff handlers. i8042_pm_suspend(), however, is only set as\nthe .suspend handler.\n\nFix the issue by call PMC suspend handler only from the same set of\ndev_pm_ops handlers as i8042_pm_suspend(), which currently means just\nthe .suspend handler.\n\nTo reproduce this issue try hibernating (S4) the machine after a fresh boot\nwithout putting it into s2idle first.\n\n[ij: edited the commit message.](CVE-2025-21645)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix kernel crash when 1588 is sent on HIP08 devices\n\nCurrently, HIP08 devices does not register the ptp devices, so the\nhdev-\u0026gt;ptp is NULL. But the tx process would still try to set hardware time\nstamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash.\n\n[  128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018\n...\n[  128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge]\n[  128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge]\n[  128.292938] sp : ffff800059b93140\n[  128.297200] x29: ffff800059b93140 x28: 0000000000003280\n[  128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080\n[  128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001\n[  128.315969] x23: 0000000000000000 x22: 0000000000000194\n[  128.322219] x21: ffff0cd94f986000 x20: 0000000000000000\n[  128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000\n[  128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24\n[  128.340934] x15: 0000ffffd530a518 x14: 0000000000000000\n[  128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368\n[  128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02\n[  128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0\n[  128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000\n[  128.372040] x5 : 0000000000000000 x4 : 000000000000ffff\n[  128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294\n[  128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080\n[  128.390626] Call trace:\n[  128.393964]  hclge_ptp_set_tx_info+0x2c/0x140 [hclge]\n[  128.399893]  hns3_nic_net_xmit+0x39c/0x4c4 [hns3]\n[  128.405468]  xmit_one.constprop.0+0xc4/0x200\n[  128.410600]  dev_hard_start_xmit+0x54/0xf0\n[  128.415556]  sch_direct_xmit+0xe8/0x634\n[  128.420246]  __dev_queue_xmit+0x224/0xc70\n[  128.425101]  dev_queue_xmit+0x1c/0x40\n[  128.429608]  ovs_vport_send+0xac/0x1a0 [openvswitch]\n[  128.435409]  do_output+0x60/0x17c [openvswitch]\n[  128.440770]  do_execute_actions+0x898/0x8c4 [openvswitch]\n[  128.446993]  ovs_execute_actions+0x64/0xf0 [openvswitch]\n[  128.453129]  ovs_dp_process_packet+0xa0/0x224 [openvswitch]\n[  128.459530]  ovs_vport_receive+0x7c/0xfc [openvswitch]\n[  128.465497]  internal_dev_xmit+0x34/0xb0 [openvswitch]\n[  128.471460]  xmit_one.constprop.0+0xc4/0x200\n[  128.476561]  dev_hard_start_xmit+0x54/0xf0\n[  128.481489]  __dev_queue_xmit+0x968/0xc70\n[  128.486330]  dev_queue_xmit+0x1c/0x40\n[  128.490856]  ip_finish_output2+0x250/0x570\n[  128.495810]  __ip_finish_output+0x170/0x1e0\n[  128.500832]  ip_finish_output+0x3c/0xf0\n[  128.505504]  ip_output+0xbc/0x160\n[  128.509654]  ip_send_skb+0x58/0xd4\n[  128.513892]  udp_send_skb+0x12c/0x354\n[  128.518387]  udp_sendmsg+0x7a8/0x9c0\n[  128.522793]  inet_sendmsg+0x4c/0x8c\n[  128.527116]  __sock_sendmsg+0x48/0x80\n[  128.531609]  __sys_sendto+0x124/0x164\n[  128.536099]  __arm64_sys_sendto+0x30/0x5c\n[  128.540935]  invoke_syscall+0x50/0x130\n[  128.545508]  el0_svc_common.constprop.0+0x10c/0x124\n[  128.551205]  do_el0_svc+0x34/0xdc\n[  128.555347]  el0_svc+0x20/0x30\n[  128.559227]  el0_sync_handler+0xb8/0xc0\n[  128.563883]  el0_sync+0x160/0x180(CVE-2025-21649)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngpio: xilinx: Convert gpio_lock to raw spinlock\n\nirq_chip functions may be called in raw spinlock context. Therefore, we\nmust also use a raw spinlock for our own internal locking.\n\nThis fixes the following lockdep splat:\n\n[    5.349336] =============================\n[    5.353349] [ BUG: Invalid wait context ]\n[    5.357361] 6.13.0-rc5+ #69 Tainted: G        W\n[    5.363031] -----------------------------\n[    5.367045] kworker/u17:1/44 is trying to lock:\n[    5.371587] ffffff88018b02c0 (\u0026amp;chip-\u0026gt;gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))\n[    5.380079] other info that might help us debug this:\n[    5.385138] context-{5:5}\n[    5.387762] 5 locks held by kworker/u17:1/44:\n[    5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204)\n[    5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205)\n[    5.411528] #2: ffffff880172c900 (\u0026amp;dev-\u0026gt;mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006)\n[    5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596)\n[    5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614)\n[    5.436472] stack backtrace:\n[    5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G        W          6.13.0-rc5+ #69\n[    5.448690] Tainted: [W]=WARN\n[    5.451656] Hardware name: xlnx,zynqmp (DT)\n[    5.455845] Workqueue: events_unbound deferred_probe_work_func\n[    5.461699] Call trace:\n[    5.464147] show_stack+0x18/0x24 C\n[    5.467821] dump_stack_lvl (lib/dump_stack.c:123)\n[    5.471501] dump_stack (lib/dump_stack.c:130)\n[    5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176)\n[    5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814)\n[    5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)\n[    5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))\n[    5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345)\n[    5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250)\n[    5.497645] irq_startup (kernel/irq/chip.c:270)\n[    5.501143] __setup_irq (kernel/irq/manage.c:1807)\n[    5.504728] request_threaded_irq (kernel/irq/manage.c:2208)(CVE-2025-21684)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-77.0.0.70.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-77.0.0.70.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-77.0.0.70.oe2403.aarch64.rpm","kernel-6.6.0-77.0.0.70.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-77.0.0.70.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-77.0.0.70.oe2403.aarch64.rpm","kernel-devel-6.6.0-77.0.0.70.oe2403.aarch64.rpm","kernel-headers-6.6.0-77.0.0.70.oe2403.aarch64.rpm","kernel-source-6.6.0-77.0.0.70.oe2403.aarch64.rpm","kernel-tools-6.6.0-77.0.0.70.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-77.0.0.70.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-77.0.0.70.oe2403.aarch64.rpm","perf-6.6.0-77.0.0.70.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-77.0.0.70.oe2403.aarch64.rpm","python3-perf-6.6.0-77.0.0.70.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-77.0.0.70.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-77.0.0.70.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-77.0.0.70.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-77.0.0.70.oe2403.x86_64.rpm","kernel-6.6.0-77.0.0.70.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-77.0.0.70.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-77.0.0.70.oe2403.x86_64.rpm","kernel-devel-6.6.0-77.0.0.70.oe2403.x86_64.rpm","kernel-headers-6.6.0-77.0.0.70.oe2403.x86_64.rpm","kernel-source-6.6.0-77.0.0.70.oe2403.x86_64.rpm","kernel-tools-6.6.0-77.0.0.70.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-77.0.0.70.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-77.0.0.70.oe2403.x86_64.rpm","perf-6.6.0-77.0.0.70.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-77.0.0.70.oe2403.x86_64.rpm","python3-perf-6.6.0-77.0.0.70.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-77.0.0.70.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1110"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43098"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46832"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47141"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47408"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-48873"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49568"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49571"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50051"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-52332"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53056"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53096"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53105"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53208"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53222"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53690"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56369"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56610"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56617"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56686"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56690"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56698"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56715"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57791"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57841"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57882"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57888"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57916"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57925"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57932"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57933"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57939"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57940"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57947"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21645"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21649"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21684"}],"database_specific":{"severity":"High"}}