{"schema_version":"1.7.2","id":"OESA-2025-2633","modified":"2025-11-07T12:30:56Z","published":"2025-11-07T12:30:56Z","upstream":["CVE-2025-21991","CVE-2025-22093","CVE-2025-37998","CVE-2025-39685","CVE-2025-39701","CVE-2025-39725","CVE-2025-39742","CVE-2025-39782","CVE-2025-39832","CVE-2025-39847","CVE-2025-39860","CVE-2025-39880","CVE-2025-39889","CVE-2025-39945","CVE-2025-39949","CVE-2025-39969","CVE-2025-39970","CVE-2025-39972","CVE-2025-39973","CVE-2025-39977","CVE-2025-40006","CVE-2025-40021","CVE-2025-40042","CVE-2025-40057","CVE-2025-40071","CVE-2025-40081","CVE-2025-40102"],"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:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst:   Some memory may share the same node as a CPU, and others are provided as  memory only nodes. Therefore, some node CPU masks may be empty and wouldn t have a  first CPU .On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an  index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat:  UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y  index 512 is out of range for type  unsigned long[512]   [...]  Call Trace:   dump_stack   __ubsan_handle_out_of_bounds   load_microcode_amd   request_microcode_amd   reload_store   kernfs_fop_write_iter   vfs_write   ksys_write   do_syscall_64   entry_SYSCALL_64_after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update.  [ bp: Massage commit message, fix typo. ](CVE-2025-21991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: avoid NPD when ASIC does not support DMUB\n\nctx->dmub_srv will de NULL if the ASIC does not support DMUB, which is\ntested in dm_dmub_sw_init.\n\nHowever, it will be dereferenced in dmub_hw_lock_mgr_cmd if\nshould_use_dmub_lock returns true.\n\nThis has been the case since dmub support has been added for PSR1.\n\nFix this by checking for dmub_srv in should_use_dmub_lock.\n\n[   37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058\n[   37.447808] #PF: supervisor read access in kernel mode\n[   37.452959] #PF: error_code(0x0000) - not-present page\n[   37.458112] PGD 0 P4D 0\n[   37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n[   37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88\n[   37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023\n[   37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0\n[   37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 <48> 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5\n[   37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202\n[   37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358\n[   37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000\n[   37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5\n[   37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000\n[   37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000\n[   37.551725] FS:  0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000\n[   37.559814] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0\n[   37.572697] Call Trace:\n[   37.575152]  <TASK>\n[   37.577258]  ? __die_body+0x66/0xb0\n[   37.580756]  ? page_fault_oops+0x3e7/0x4a0\n[   37.584861]  ? exc_page_fault+0x3e/0xe0\n[   37.588706]  ? exc_page_fault+0x5c/0xe0\n[   37.592550]  ? asm_exc_page_fault+0x22/0x30\n[   37.596742]  ? dmub_hw_lock_mgr_cmd+0x77/0xb0\n[   37.601107]  dcn10_cursor_lock+0x1e1/0x240\n[   37.605211]  program_cursor_attributes+0x81/0x190\n[   37.609923]  commit_planes_for_stream+0x998/0x1ef0\n[   37.614722]  update_planes_and_stream_v2+0x41e/0x5c0\n[   37.619703]  dc_update_planes_and_stream+0x78/0x140\n[   37.624588]  amdgpu_dm_atomic_commit_tail+0x4362/0x49f0\n[   37.629832]  ? srso_return_thunk+0x5/0x5f\n[   37.633847]  ? mark_held_locks+0x6d/0xd0\n[   37.637774]  ? _raw_spin_unlock_irq+0x24/0x50\n[   37.642135]  ? srso_return_thunk+0x5/0x5f\n[   37.646148]  ? lockdep_hardirqs_on+0x95/0x150\n[   37.650510]  ? srso_return_thunk+0x5/0x5f\n[   37.654522]  ? _raw_spin_unlock_irq+0x2f/0x50\n[   37.658883]  ? srso_return_thunk+0x5/0x5f\n[   37.662897]  ? wait_for_common+0x186/0x1c0\n[   37.666998]  ? srso_return_thunk+0x5/0x5f\n[   37.671009]  ? drm_crtc_next_vblank_start+0xc3/0x170\n[   37.675983]  commit_tail+0xf5/0x1c0\n[   37.679478]  drm_atomic_helper_commit+0x2a2/0x2b0\n[   37.684186]  drm_atomic_commit+0xd6/0x100\n[   37.688199]  ? __cfi___drm_printfn_info+0x10/0x10\n[   37.692911]  drm_atomic_helper_update_plane+0xe5/0x130\n[   37.698054]  drm_mode_cursor_common+0x501/0x670\n[   37.702600]  ? __cfi_drm_mode_cursor_ioctl+0x10/0x10\n[   37.707572]  drm_mode_cursor_ioctl+0x48/0x70\n[   37.711851]  drm_ioctl_kernel+0xf2/0x150\n[   37.715781]  drm_ioctl+0x363/0x590\n[   37.719189]  ? __cfi_drm_mode_cursor_ioctl+0x10/0x10\n[   37.724165]  amdgpu_drm_ioctl+0x41/0x80\n[   37.728013]  __se_sys_ioctl+0x7f/0xd0\n[   37.731685]  do_syscall_64+0x87/0x100\n[   37.735355]  ? vma_end_read+0x12/0xe0\n[   37.739024]  ? srso_return_thunk+0x5/0x5f\n[   37.743041]  ? find_held_lock+0x47/0xf0\n[   37.746884]  ? vma_end_read+0x12/0xe0\n[   37.750552]  ? srso_return_thunk+0x5/0\n---truncated---(CVE-2025-22093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: Fix unsafe attribute parsing in output_userspace()\n\nThis patch replaces the manual Netlink attribute iteration in\noutput_userspace() with nla_for_each_nested(), which ensures that only\nwell-formed attributes are processed.(CVE-2025-37998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: pcl726: Prevent invalid irq number\n\nThe reproducer passed in an irq number(0x80008000) that was too large,\nwhich triggered the oob.\n\nAdded an interrupt number check to prevent users from passing in an irq\nnumber that was too large.\n\nIf `it->options[1]` is 31, then `1 << it->options[1]` is still invalid\nbecause it shifts a 1-bit into the sign bit (which is UB in C).\nPossible solutions include reducing the upper bound on the\n`it->options[1]` value to 30 or lower, or using `1U << it->options[1]`.\n\nThe old code would just not attempt to request the IRQ if the\n`options[1]` value were invalid.  And it would still configure the\ndevice without interrupts even if the call to `request_irq` returned an\nerror.  So it would be better to combine this test with the test below.(CVE-2025-39685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPI: pfr_update: Fix the driver update version check\n\nThe security-version-number check should be used rather\nthan the runtime version check for driver updates.\n\nOtherwise, the firmware update would fail when the update binary had\na lower runtime version number than the current one.\n\n[ rjw: Changelog edits ](CVE-2025-39701)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan't be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn't in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough.  memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic.  The race is as\nfollows:\n\ncpu0      cpu1\n shrink_folio_list memory_failure\n  TestSetPageHWPoison\n  unmap_poisoned_folio\n  --> trigger BUG_ON due to\n  unmap_poisoned_folio couldn't\n   handle large folio\n\n[(CVE-2025-39725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()\n\nThe function divides number of online CPUs by num_core_siblings, and\nlater checks the divider by zero. This implies a possibility to get\nand divide-by-zero runtime error. Fix it by moving the check prior to\ndivision. This also helps to save one indentation level.(CVE-2025-39742)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: prevent softlockup in jbd2_log_do_checkpoint()\n\nBoth jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()\nperiodically release j_list_lock after processing a batch of buffers to\navoid long hold times on the j_list_lock. However, since both functions\ncontend for j_list_lock, the combined time spent waiting and processing\ncan be significant.\n\njbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when\nneed_resched() is true to avoid softlockups during prolonged operations.\nBut jbd2_log_do_checkpoint() only exits its loop when need_resched() is\ntrue, relying on potentially sleeping functions like __flush_batch() or\nwait_on_buffer() to trigger rescheduling. If those functions do not sleep,\nthe kernel may hit a softlockup.\n\nwatchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]\nCPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10\nHardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017\nWorkqueue: writeback wb_workfn (flush-7:2)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : native_queued_spin_lock_slowpath+0x358/0x418\nlr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\nCall trace:\n native_queued_spin_lock_slowpath+0x358/0x418\n jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\n __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]\n add_transaction_credits+0x3bc/0x418 [jbd2]\n start_this_handle+0xf8/0x560 [jbd2]\n jbd2__journal_start+0x118/0x228 [jbd2]\n __ext4_journal_start_sb+0x110/0x188 [ext4]\n ext4_do_writepages+0x3dc/0x740 [ext4]\n ext4_writepages+0xa4/0x190 [ext4]\n do_writepages+0x94/0x228\n __writeback_single_inode+0x48/0x318\n writeback_sb_inodes+0x204/0x590\n __writeback_inodes_wb+0x54/0xf8\n wb_writeback+0x2cc/0x3d8\n wb_do_writeback+0x2e0/0x2f8\n wb_workfn+0x80/0x2a8\n process_one_work+0x178/0x3e8\n worker_thread+0x234/0x3b8\n kthread+0xf0/0x108\n ret_from_fork+0x10/0x20\n\nSo explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid\nsoftlockup.(CVE-2025-39782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix lockdep assertion on sync reset unload event\n\nFix lockdep assertion triggered during sync reset unload event. When the\nsync reset flow is initiated using the devlink reload fw_activate\noption, the PF already holds the devlink lock while handling unload\nevent. In this case, delegate sync reset unload event handling back to\nthe devlink callback process to avoid double-locking and resolve the\nlockdep warning.\n\nKernel log:\nWARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40\n[...]\nCall Trace:\n<TASK>\n mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core]\n mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core]\n process_one_work+0x222/0x640\n worker_thread+0x199/0x350\n kthread+0x10b/0x230\n ? __pfx_worker_thread+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x8e/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n</TASK>(CVE-2025-39832)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: fix memory leak in pad_compress_skb\n\nIf alloc_skb() fails in pad_compress_skb(), it returns NULL without\nreleasing the old skb. The caller does:\n\n    skb = pad_compress_skb(ppp, skb);\n    if (!skb)\n        goto drop;\n\ndrop:\n    kfree_skb(skb);\n\nWhen pad_compress_skb() returns NULL, the reference to the old skb is\nlost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.\n\nAlign pad_compress_skb() semantics with realloc(): only free the old\nskb if allocation and compression succeed.  At the call site, use the\nnew_skb variable so the original skb is not lost when pad_compress_skb()\nfails.(CVE-2025-39847)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()\n\nsyzbot reported the splat below without a repro.\n\nIn the splat, a single thread calling bt_accept_dequeue() freed sk\nand touched it after that.\n\nThe root cause would be the racy l2cap_sock_cleanup_listen() call\nadded by the cited commit.\n\nbt_accept_dequeue() is called under lock_sock() except for\nl2cap_sock_release().\n\nTwo threads could see the same socket during the list iteration\nin bt_accept_dequeue():\n\n  CPU1                        CPU2 (close())\n  ----                        ----\n  sock_hold(sk)               sock_hold(sk);\n  lock_sock(sk)   <-- block close()\n  sock_put(sk)\n  bt_accept_unlink(sk)\n    sock_put(sk)  <-- refcnt by bt_accept_enqueue()\n  release_sock(sk)\n                              lock_sock(sk)\n                              sock_put(sk)\n                              bt_accept_unlink(sk)\n                                sock_put(sk)        <-- last refcnt\n                              bt_accept_unlink(sk)  <-- UAF\n\nDepending on the timing, the other thread could show up in the\n"Freed by task" part.\n\nLet's call l2cap_sock_cleanup_listen() under lock_sock() in\nl2cap_sock_release().\n\n[0]:\nBUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\nBUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\nRead of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995\nCPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcd/0x630 mm/kasan/report.c:482\n kasan_report+0xe0/0x110 mm/kasan/report.c:595\n debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\n do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\n spin_lock_bh include/linux/spinlock.h:356 [inline]\n release_sock+0x21/0x220 net/core/sock.c:3746\n bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312\n l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451\n l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425\n __sock_release+0xb3/0x270 net/socket.c:649\n sock_close+0x1c/0x30 net/socket.c:1439\n __fput+0x3ff/0xb70 fs/file_table.c:468\n task_work_run+0x14d/0x240 kernel/task_work.c:227\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43\n exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]\n do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f2accf8ebe9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4\nRAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9\nRDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003\nRBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f\nR10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c\nR13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490\n </TASK>\n\nAllocated by task 5326:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:388 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4365 [inline]\n __kmalloc_nopro\n---truncated---(CVE-2025-39860)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix invalid accesses to ceph_connection_v1_info\n\nThere is a place where generic code in messenger.c is reading and\nanother place where it is writing to con->v1 union member without\nchecking that the union member is active (i.e. msgr1 is in use).\n\nOn 64-bit systems, con->v1.auth_retry overlaps with con->v2.out_iter,\nso such a read is almost guaranteed to return a bogus value instead of\n0 when msgr2 is in use.  This ends up being fairly benign because the\nside effect is just the invalidation of the authorizer and successive\nfetching of new tickets.\n\ncon->v1.connect_seq overlaps with con->v2.conn_bufs and the fact that\nit's being written to can cause more serious consequences, but luckily\nit's not something that happens often.(CVE-2025-39880)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: l2cap: Check encryption key size on incoming connection\n\nThis is required for passing GAP/SEC/SEM/BI-04-C PTS test case:\n  Security Mode 4 Level 4, Responder - Invalid Encryption Key Size\n  - 128 bit\n\nThis tests the security key with size from 1 to 15 bytes while the\nSecurity Mode 4 Level 4 requests 16 bytes key size.\n\nCurrently PTS fails with the following logs:\n- expected:Connection Response:\n    Code: [3 (0x03)] Code\n    Identifier: (lt)WildCard: Exists(gt)\n    Length: [8 (0x0008)]\n    Destination CID: (lt)WildCard: Exists(gt)\n    Source CID: [64 (0x0040)]\n    Result: [3 (0x0003)] Connection refused - Security block\n    Status: (lt)WildCard: Exists(gt),\nbut received:Connection Response:\n    Code: [3 (0x03)] Code\n    Identifier: [1 (0x01)]\n    Length: [8 (0x0008)]\n    Destination CID: [64 (0x0040)]\n    Source CID: [64 (0x0040)]\n    Result: [0 (0x0000)] Connection Successful\n    Status: [0 (0x0000)] No further information available\n\nAnd HCI logs:\n< HCI Command: Read Encrypti.. (0x05|0x0008) plen 2\n        Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)\n> HCI Event: Command Complete (0x0e) plen 7\n      Read Encryption Key Size (0x05|0x0008) ncmd 1\n        Status: Success (0x00)\n        Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)\n        Key size: 7\n> ACL Data RX: Handle 14 flags 0x02 dlen 12\n      L2CAP: Connection Request (0x02) ident 1 len 4\n        PSM: 4097 (0x1001)\n        Source CID: 64\n< ACL Data TX: Handle 14 flags 0x00 dlen 16\n      L2CAP: Connection Response (0x03) ident 1 len 8\n        Destination CID: 64\n        Source CID: 64\n        Result: Connection successful (0x0000)\n        Status: No further information available (0x0000)(CVE-2025-39889)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncnic: Fix use-after-free bugs in cnic_delete_task\n\nThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),\nwhich does not guarantee that the delayed work item 'delete_task' has\nfully completed if it was already running. Additionally, the delayed work\nitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only\nblocks and waits for work items that were already queued to the\nworkqueue prior to its invocation. Any work items submitted after\nflush_workqueue() is called are not included in the set of tasks that the\nflush operation awaits. This means that after the cyclic work items have\nfinished executing, a delayed work item may still exist in the workqueue.\nThis leads to use-after-free scenarios where the cnic_dev is deallocated\nby cnic_free_dev(), while delete_task remains active and attempt to\ndereference cnic_dev in cnic_delete_task().\n\nA typical race condition is illustrated below:\n\nCPU 0 (cleanup)              | CPU 1 (delayed work callback)\ncnic_netdev_event()          |\n  cnic_stop_hw()             | cnic_delete_task()\n    cnic_cm_stop_bnx2x_hw()  | ...\n      cancel_delayed_work()  | /* the queue_delayed_work()\n      flush_workqueue()      |    executes after flush_workqueue()*/\n                             | queue_delayed_work()\n  cnic_free_dev(dev)//free   | cnic_delete_task() //new instance\n                             |   dev = cp->dev; //use\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the cyclic delayed work item is properly canceled and that any\nongoing execution of the work item completes before the cnic_dev is\ndeallocated. Furthermore, since cancel_delayed_work_sync() uses\n__flush_work(work, true) to synchronously wait for any currently\nexecuting instance of the work item to finish, the flush_workqueue()\nbecomes redundant and should be removed.\n\nThis bug was identified through static analysis. To reproduce the issue\nand validate the fix, I simulated the cnic PCI device in QEMU and\nintroduced intentional delays — such as inserting calls to ssleep()\nwithin the cnic_delete_task() function — to increase the likelihood\nof triggering the bug.(CVE-2025-39945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqed: Don't collect too many protection override GRC elements\n\nIn the protection override dump path, the firmware can return far too\nmany GRC elements, resulting in attempting to write past the end of the\npreviously-kmalloc'ed dump buffer.\n\nThis will result in a kernel panic with reason:\n\n BUG: unable to handle kernel paging request at ADDRESS\n\nwhere "ADDRESS" is just past the end of the protection override dump\nbuffer. The start address of the buffer is:\n p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf\nand the size of the buffer is buf_size in the same data structure.\n\nThe panic can be arrived at from either the qede Ethernet driver path:\n\n    [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc02662ed [qed]\n qed_dbg_protection_override_dump at ffffffffc0267792 [qed]\n qed_dbg_feature at ffffffffc026aa8f [qed]\n qed_dbg_all_data at ffffffffc026b211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]\n devlink_health_do_dump at ffffffff82497f61\n devlink_health_report at ffffffff8249cf29\n qed_report_fatal_error at ffffffffc0272baf [qed]\n qede_sp_task at ffffffffc045ed32 [qede]\n process_one_work at ffffffff81d19783\n\nor the qedf storage driver path:\n\n    [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc068b2ed [qed]\n qed_dbg_protection_override_dump at ffffffffc068c792 [qed]\n qed_dbg_feature at ffffffffc068fa8f [qed]\n qed_dbg_all_data at ffffffffc0690211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]\n devlink_health_do_dump at ffffffff8aa95e51\n devlink_health_report at ffffffff8aa9ae19\n qed_report_fatal_error at ffffffffc0697baf [qed]\n qed_hw_err_notify at ffffffffc06d32d7 [qed]\n qed_spq_post at ffffffffc06b1011 [qed]\n qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]\n qedf_cleanup_fcport at ffffffffc05e7597 [qedf]\n qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]\n fc_rport_work at ffffffffc02da715 [libfc]\n process_one_work at ffffffff8a319663\n\nResolve this by clamping the firmware's return value to the maximum\nnumber of legal elements the firmware should return.(CVE-2025-39949)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix validation of VF state in get resources\n\nVF state I40E_VF_STATE_ACTIVE is not the only state in which\nVF is actually active so it should not be used to determine\nif a VF is allowed to obtain resources.\n\nUse I40E_VF_STATE_RESOURCES_LOADED that is set only in\ni40e_vc_get_vf_resources_msg() and cleared during reset.(CVE-2025-39969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix input validation logic for action_meta\n\nFix condition to check 'greater or equal' to prevent OOB dereference.(CVE-2025-39970)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix idx validation in i40e_validate_queue_map\n\nEnsure idx is within range of active/initialized TCs when iterating over\nvf->ch[idx] in i40e_validate_queue_map().(CVE-2025-39972)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add validation for ring_len param\n\nThe `ring_len` parameter provided by the virtual function (VF)\nis assigned directly to the hardware memory context (HMC) without\nany validation.\n\nTo address this, introduce an upper boundary check for both Tx and Rx\nqueue lengths. The maximum number of descriptors supported by the\nhardware is 8k-32.\nAdditionally, enforce alignment constraints: Tx rings must be a multiple\nof 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfutex: Prevent use-after-free during requeue-PI\n\nsyzbot managed to trigger the following race:\n\n   T1                               T2\n\n futex_wait_requeue_pi()\n   futex_do_wait()\n     schedule()\n                               futex_requeue()\n                                 futex_proxy_trylock_atomic()\n                                   futex_requeue_pi_prepare()\n                                   requeue_pi_wake_futex()\n                                     futex_requeue_pi_complete()\n                                      /* preempt */\n\n         * timeout/ signal wakes T1 *\n\n   futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED\n   futex_hash_put()\n  // back to userland, on stack futex_q is garbage\n\n                                      /* back */\n                                     wake_up_state(q->task, TASK_NORMAL);\n\nIn this scenario futex_wait_requeue_pi() is able to leave without using\nfutex_q::lock_ptr for synchronization.\n\nThis can be prevented by reading futex_q::task before updating the\nfutex_q::requeue_state. A reference on the task_struct is not needed\nbecause requeue_pi_wake_futex() is invoked with a spinlock_t held which\nimplies a RCU read section.\n\nEven if T1 terminates immediately after, the task_struct will remain valid\nduring T2's wake_up_state().  A READ_ONCE on futex_q::task before\nfutex_requeue_pi_complete() is enough because it ensures that the variable\nis read before the state is updated.\n\nRead futex_q::task before updating the requeue state, use it for the\nfollowing wakeup.(CVE-2025-39977)\n\nIn the Linux kernel, a race condition vulnerability exists in the mm/hugetlb subsystem. Migration may race with fallocating hole operations. The remove_inode_single_folio function checks if the folio is still mapped without holding the folio lock. If the folio is migrated and the mapped page table entry has been converted to a migration entry, folio_mapped() returns false and fails to unmap it. Due to the extra refcount held by remove_inode_single_folio, migration fails, restores the migration entry to a normal page table entry, and the folio is mapped again, ultimately triggering a BUG in filemap_unaccount_folio.(CVE-2025-40006)\n\nIn the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)\n\nThere is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perf_events initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perf_events pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/trace_kprobe.c at line 1308, the kprobe_perf_func function attempts to access the call->perf_events pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)\n\nIn the Linux kernel, a vulnerability has been identified in the PTP (Precision Time Protocol) subsystem. syzbot reported a WARNING in max_vclocks_store function. This occurs when the max argument is too large for kcalloc to handle, leading to potential buffer overflow. The vulnerability is resolved by adding an upper bound on max_vclocks.(CVE-2025-40057)\n\nIn the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Don t block input queue by waiting MSCCurrently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue.Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used.(CVE-2025-40071)\n\nIn the Linux kernel, an integer overflow vulnerability exists in the arm_spe component of the perf subsystem. The PERF_IDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (>= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)\n\nIn the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn t been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection. Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway.(CVE-2025-40102)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-115.0.0.108.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-115.0.0.108.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-115.0.0.108.oe2403.aarch64.rpm","kernel-6.6.0-115.0.0.108.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-115.0.0.108.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-115.0.0.108.oe2403.aarch64.rpm","kernel-devel-6.6.0-115.0.0.108.oe2403.aarch64.rpm","kernel-headers-6.6.0-115.0.0.108.oe2403.aarch64.rpm","kernel-source-6.6.0-115.0.0.108.oe2403.aarch64.rpm","kernel-tools-6.6.0-115.0.0.108.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-115.0.0.108.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-115.0.0.108.oe2403.aarch64.rpm","perf-6.6.0-115.0.0.108.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-115.0.0.108.oe2403.aarch64.rpm","python3-perf-6.6.0-115.0.0.108.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-115.0.0.108.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-115.0.0.108.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-115.0.0.108.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-115.0.0.108.oe2403.x86_64.rpm","kernel-6.6.0-115.0.0.108.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-115.0.0.108.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-115.0.0.108.oe2403.x86_64.rpm","kernel-devel-6.6.0-115.0.0.108.oe2403.x86_64.rpm","kernel-headers-6.6.0-115.0.0.108.oe2403.x86_64.rpm","kernel-source-6.6.0-115.0.0.108.oe2403.x86_64.rpm","kernel-tools-6.6.0-115.0.0.108.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-115.0.0.108.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-115.0.0.108.oe2403.x86_64.rpm","perf-6.6.0-115.0.0.108.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-115.0.0.108.oe2403.x86_64.rpm","python3-perf-6.6.0-115.0.0.108.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-115.0.0.108.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2633"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21991"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22093"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37998"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39685"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39701"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39725"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39742"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39782"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39832"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39847"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39860"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39880"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39889"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39945"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39949"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39969"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39970"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39972"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39973"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39977"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40006"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40021"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40042"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40057"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40071"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40081"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40102"}],"database_specific":{"severity":"High"}}