{"schema_version":"1.7.2","id":"OESA-2026-1275","modified":"2026-01-30T12:28:47Z","published":"2026-01-30T12:28:47Z","upstream":["CVE-2022-49157","CVE-2022-50583","CVE-2022-50737","CVE-2023-53680","CVE-2023-53794","CVE-2023-54263","CVE-2025-37740","CVE-2025-37768","CVE-2025-38051","CVE-2025-38102","CVE-2025-38103","CVE-2025-38111","CVE-2025-38342","CVE-2025-38697","CVE-2025-38705","CVE-2025-38712","CVE-2025-38713","CVE-2025-38714","CVE-2025-39691","CVE-2025-39737","CVE-2025-39823","CVE-2025-39839","CVE-2025-39951","CVE-2025-39968","CVE-2025-40111","CVE-2025-40178","CVE-2025-40259","CVE-2025-68229","CVE-2025-68354","CVE-2025-68800","CVE-2025-68801","CVE-2025-71087","CVE-2025-71093","CVE-2025-71104","CVE-2025-71125"],"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\nscsi: qla2xxx: Fix premature hw access after PCI error\n\nAfter a recoverable PCI error has been detected and recovered, qla driver\nneeds to check to see if the error condition still persist and/or wait\nfor the OS to give the resume signal.\n\nSep  8 22:26:03 localhost kernel: WARNING: CPU: 9 PID: 124606 at qla_tmpl.c:440\nqla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx]\nSep  8 22:26:03 localhost kernel: RIP: 0010:qla27xx_fwdt_entry_t266+0x55/0x60\n[qla2xxx]\nSep  8 22:26:03 localhost kernel: Call Trace:\nSep  8 22:26:03 localhost kernel: ? qla27xx_walk_template+0xb1/0x1b0 [qla2xxx]\nSep  8 22:26:03 localhost kernel: ? qla27xx_execute_fwdt_template+0x12a/0x160\n[qla2xxx]\nSep  8 22:26:03 localhost kernel: ? qla27xx_fwdump+0xa0/0x1c0 [qla2xxx]\nSep  8 22:26:03 localhost kernel: ? qla2xxx_pci_mmio_enabled+0xfb/0x120\n[qla2xxx]\nSep  8 22:26:03 localhost kernel: ? report_mmio_enabled+0x44/0x80\nSep  8 22:26:03 localhost kernel: ? report_slot_reset+0x80/0x80\nSep  8 22:26:03 localhost kernel: ? pci_walk_bus+0x70/0x90\nSep  8 22:26:03 localhost kernel: ? aer_dev_correctable_show+0xc0/0xc0\nSep  8 22:26:03 localhost kernel: ? pcie_do_recovery+0x1bb/0x240\nSep  8 22:26:03 localhost kernel: ? aer_recover_work_func+0xaa/0xd0\nSep  8 22:26:03 localhost kernel: ? process_one_work+0x1a7/0x360\n..\nSep  8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-8041:22: detected PCI\ndisconnect.\nSep  8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22:\nqla27xx_fwdt_entry_t262: dump ram MB failed. Area 5h start 198013h end 198013h\nSep  8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: Unable to\ncapture FW dump\nSep  8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-1015:22: cmd=0x0,\nwaited 5221 msecs\nSep  8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-680d:22: mmio\nenabled returning.\nSep  8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-d04c:22: MBX\nCommand timeout for cmd 0, iocontrol=ffffffff jiffies=10140f2e5\nmb[0-3]=[0xffff 0xffff 0xffff 0xffff](CVE-2022-49157)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid0, raid10: Don't set discard sectors for request queue\n\nIt should use disk_stack_limits to get a proper max_discard_sectors\nrather than setting a value by stack drivers.\n\nAnd there is a bug. If all member disks are rotational devices,\nraid0/raid10 set max_discard_sectors. So the member devices are\nnot ssd/nvme, but raid0/raid10 export the wrong value. It reports\nwarning messages in function __blkdev_issue_discard when mkfs.xfs\nlike this:\n\n[ 4616.022599] ------------[ cut here ]------------\n[ 4616.027779] WARNING: CPU: 4 PID: 99634 at block/blk-lib.c:50 __blkdev_issue_discard+0x16a/0x1a0\n[ 4616.140663] RIP: 0010:__blkdev_issue_discard+0x16a/0x1a0\n[ 4616.146601] Code: 24 4c 89 20 31 c0 e9 fe fe ff ff c1 e8 09 8d 48 ff 4c 89 f0 4c 09 e8 48 85 c1 0f 84 55 ff ff ff b8 ea ff ff ff e9 df fe ff ff <0f> 0b 48 8d 74 24 08 e8 ea d6 00 00 48 c7 c6 20 1e 89 ab 48 c7 c7\n[ 4616.167567] RSP: 0018:ffffaab88cbffca8 EFLAGS: 00010246\n[ 4616.173406] RAX: ffff9ba1f9e44678 RBX: 0000000000000000 RCX: ffff9ba1c9792080\n[ 4616.181376] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ba1c9792080\n[ 4616.189345] RBP: 0000000000000cc0 R08: ffffaab88cbffd10 R09: 0000000000000000\n[ 4616.197317] R10: 0000000000000012 R11: 0000000000000000 R12: 0000000000000000\n[ 4616.205288] R13: 0000000000400000 R14: 0000000000000cc0 R15: ffff9ba1c9792080\n[ 4616.213259] FS:  00007f9a5534e980(0000) GS:ffff9ba1b7c80000(0000) knlGS:0000000000000000\n[ 4616.222298] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 4616.228719] CR2: 000055a390a4c518 CR3: 0000000123e40006 CR4: 00000000001706e0\n[ 4616.236689] Call Trace:\n[ 4616.239428]  blkdev_issue_discard+0x52/0xb0\n[ 4616.244108]  blkdev_common_ioctl+0x43c/0xa00\n[ 4616.248883]  blkdev_ioctl+0x116/0x280\n[ 4616.252977]  __x64_sys_ioctl+0x8a/0xc0\n[ 4616.257163]  do_syscall_64+0x5c/0x90\n[ 4616.261164]  ? handle_mm_fault+0xc5/0x2a0\n[ 4616.265652]  ? do_user_addr_fault+0x1d8/0x690\n[ 4616.270527]  ? do_syscall_64+0x69/0x90\n[ 4616.274717]  ? exc_page_fault+0x62/0x150\n[ 4616.279097]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 4616.284748] RIP: 0033:0x7f9a55398c6b(CVE-2022-50583)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Validate index root when initialize NTFS security\n\nThis enhances the sanity check for $SDH and $SII while initializing NTFS\nsecurity, guarantees these index root are legit.\n\n[  162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320\n[  162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243\n[  162.460851]\n[  162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42\n[  162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[  162.462609] Call Trace:\n[  162.462954]  <TASK>\n[  162.463276]  dump_stack_lvl+0x49/0x63\n[  162.463822]  print_report.cold+0xf5/0x689\n[  162.464608]  ? unwind_get_return_address+0x3a/0x60\n[  162.465766]  ? hdr_find_e.isra.0+0x10c/0x320\n[  162.466975]  kasan_report+0xa7/0x130\n[  162.467506]  ? _raw_spin_lock_irq+0xc0/0xf0\n[  162.467998]  ? hdr_find_e.isra.0+0x10c/0x320\n[  162.468536]  __asan_load2+0x68/0x90\n[  162.468923]  hdr_find_e.isra.0+0x10c/0x320\n[  162.469282]  ? cmp_uints+0xe0/0xe0\n[  162.469557]  ? cmp_sdh+0x90/0x90\n[  162.469864]  ? ni_find_attr+0x214/0x300\n[  162.470217]  ? ni_load_mi+0x80/0x80\n[  162.470479]  ? entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[  162.470931]  ? ntfs_bread_run+0x190/0x190\n[  162.471307]  ? indx_get_root+0xe4/0x190\n[  162.471556]  ? indx_get_root+0x140/0x190\n[  162.471833]  ? indx_init+0x1e0/0x1e0\n[  162.472069]  ? fnd_clear+0x115/0x140\n[  162.472363]  ? _raw_spin_lock_irqsave+0x100/0x100\n[  162.472731]  indx_find+0x184/0x470\n[  162.473461]  ? sysvec_apic_timer_interrupt+0x57/0xc0\n[  162.474429]  ? indx_find_buffer+0x2d0/0x2d0\n[  162.474704]  ? do_syscall_64+0x3b/0x90\n[  162.474962]  dir_search_u+0x196/0x2f0\n[  162.475381]  ? ntfs_nls_to_utf16+0x450/0x450\n[  162.475661]  ? ntfs_security_init+0x3d6/0x440\n[  162.475906]  ? is_sd_valid+0x180/0x180\n[  162.476191]  ntfs_extend_init+0x13f/0x2c0\n[  162.476496]  ? ntfs_fix_post_read+0x130/0x130\n[  162.476861]  ? iput.part.0+0x286/0x320\n[  162.477325]  ntfs_fill_super+0x11e0/0x1b50\n[  162.477709]  ? put_ntfs+0x1d0/0x1d0\n[  162.477970]  ? vsprintf+0x20/0x20\n[  162.478258]  ? set_blocksize+0x95/0x150\n[  162.478538]  get_tree_bdev+0x232/0x370\n[  162.478789]  ? put_ntfs+0x1d0/0x1d0\n[  162.479038]  ntfs_fs_get_tree+0x15/0x20\n[  162.479374]  vfs_get_tree+0x4c/0x130\n[  162.479729]  path_mount+0x654/0xfe0\n[  162.480124]  ? putname+0x80/0xa0\n[  162.480484]  ? finish_automount+0x2e0/0x2e0\n[  162.480894]  ? putname+0x80/0xa0\n[  162.481467]  ? kmem_cache_free+0x1c4/0x440\n[  162.482280]  ? putname+0x80/0xa0\n[  162.482714]  do_mount+0xd6/0xf0\n[  162.483264]  ? path_mount+0xfe0/0xfe0\n[  162.484782]  ? __kasan_check_write+0x14/0x20\n[  162.485593]  __x64_sys_mount+0xca/0x110\n[  162.486024]  do_syscall_64+0x3b/0x90\n[  162.486543]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[  162.487141] RIP: 0033:0x7f9d374e948a\n[  162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008\n[  162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5\n[  162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a\n[  162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0\n[  162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020\n[  162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0\n[  162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff\n[  162.493644]  </TASK>\n[  162.493908]\n[  162.494214] The buggy address belongs to the physical page:\n[  162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc\n[  162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)\n[  162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000\n[  162.498928] raw: 0000000000000000 0000000000240000 0\n---truncated---(CVE-2022-50737)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGAL\n\nOPDESC() simply indexes into nfsd4_ops[] by the op's operation\nnumber, without range checking that value. It assumes callers are\ncareful to avoid calling it with an out-of-bounds opnum value.\n\nnfsd4_decode_compound() is not so careful, and can invoke OPDESC()\nwith opnum set to OP_ILLEGAL, which is 10044 -- well beyond the end\nof nfsd4_ops[].(CVE-2023-53680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix session state check in reconnect to avoid use-after-free issue\n\nDon't collect exiting session in smb2_reconnect_server(), because it\nwill be released soon.\n\nNote that the exiting session will stay in server->smb_ses_list until\nit complete the cifs_free_ipc() and logoff() and then delete itself\nfrom the list.(CVE-2023-53794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DP\n\nFixes OOPS on boards with ANX9805 DP encoders.(CVE-2023-54263)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: add sanity check for agwidth in dbMount\n\nThe width in dmapctl of the AG is zero, it trigger a divide error when\ncalculating the control page level in dbAllocAG.\n\nTo avoid this issue, add a check for agwidth in dbAllocAG.(CVE-2025-37740)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Prevent division by zero\n\nThe user can set any speed value.\nIf speed is greater than UINT_MAX/8, division by zero is possible.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37768)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Fix use-after-free in cifs_fill_dirent\n\nThere is a race condition in the readdir concurrency process, which may\naccess the rsp buffer after it has been released, triggering the\nfollowing KASAN warning.\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs]\n Read of size 4 at addr ffff8880099b819c by task a.out/342975\n\n CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full)\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014\n Call Trace:\n  <TASK>\n  dump_stack_lvl+0x53/0x70\n  print_report+0xce/0x640\n  kasan_report+0xb8/0xf0\n  cifs_fill_dirent+0xb03/0xb60 [cifs]\n  cifs_readdir+0x12cb/0x3190 [cifs]\n  iterate_dir+0x1a1/0x520\n  __x64_sys_getdents+0x134/0x220\n  do_syscall_64+0x4b/0x110\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f996f64b9f9\n Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89\n f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01\n f0 ff ff  0d f7 c3 0c 00 f7 d8 64 89 8\n RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e\n RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\n RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88\n R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000\n  </TASK>\n\n Allocated by task 408:\n  kasan_save_stack+0x20/0x40\n  kasan_save_track+0x14/0x30\n  __kasan_slab_alloc+0x6e/0x70\n  kmem_cache_alloc_noprof+0x117/0x3d0\n  mempool_alloc_noprof+0xf2/0x2c0\n  cifs_buf_get+0x36/0x80 [cifs]\n  allocate_buffers+0x1d2/0x330 [cifs]\n  cifs_demultiplex_thread+0x22b/0x2690 [cifs]\n  kthread+0x394/0x720\n  ret_from_fork+0x34/0x70\n  ret_from_fork_asm+0x1a/0x30\n\n Freed by task 342979:\n  kasan_save_stack+0x20/0x40\n  kasan_save_track+0x14/0x30\n  kasan_save_free_info+0x3b/0x60\n  __kasan_slab_free+0x37/0x50\n  kmem_cache_free+0x2b8/0x500\n  cifs_buf_release+0x3c/0x70 [cifs]\n  cifs_readdir+0x1c97/0x3190 [cifs]\n  iterate_dir+0x1a1/0x520\n  __x64_sys_getdents64+0x134/0x220\n  do_syscall_64+0x4b/0x110\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n The buggy address belongs to the object at ffff8880099b8000\n  which belongs to the cache cifs_request of size 16588\n The buggy address is located 412 bytes inside of\n  freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8\n head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n anon flags: 0x80000000000040(head|node=0|zone=1)\n page_type: f5(slab)\n raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001\n raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000\n head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001\n head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000\n head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff\n head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n  ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n  ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                             ^\n  ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n  ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ==================================================================\n\nPOC is available in the link [1].\n\nThe problem triggering process is as follows:\n\nProcess 1                       Process 2\n-----------------------------------\n---truncated---(CVE-2025-38051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify\n\nDuring our test, it is found that a warning can be trigger in try_grab_folio\nas follow:\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130\n  Modules linked in:\n  CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)\n  RIP: 0010:try_grab_folio+0x106/0x130\n  Call Trace:\n   <TASK>\n   follow_huge_pmd+0x240/0x8e0\n   follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0\n   follow_pud_mask.constprop.0.isra.0+0x14a/0x170\n   follow_page_mask+0x1c2/0x1f0\n   __get_user_pages+0x176/0x950\n   __gup_longterm_locked+0x15b/0x1060\n   ? gup_fast+0x120/0x1f0\n   gup_fast_fallback+0x17e/0x230\n   get_user_pages_fast+0x5f/0x80\n   vmci_host_unlocked_ioctl+0x21c/0xf80\n  RIP: 0033:0x54d2cd\n  ---[ end trace 0000000000000000 ]---\n\nDigging into the source, context->notify_page may init by get_user_pages_fast\nand can be seen in vmci_ctx_unset_notify which will try to put_page. However\nget_user_pages_fast is not finished here and lead to following\ntry_grab_folio warning. The race condition is shown as follow:\n\ncpu0\t\t\tcpu1\nvmci_host_do_set_notify\nvmci_host_setup_notify\nget_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);\nlockless_pages_from_mm\ngup_pgd_range\ngup_huge_pmd  // update &context->notify_page\n\t\t\tvmci_host_do_set_notify\n\t\t\tvmci_ctx_unset_notify\n\t\t\tnotify_page = context->notify_page;\n\t\t\tif (notify_page)\n\t\t\tput_page(notify_page);\t// page is freed\n__gup_longterm_locked\n__get_user_pages\nfollow_trans_huge_pmd\ntry_grab_folio // warn here\n\nTo slove this, use local variable page to make notify_page can be seen\nafter finish get_user_pages_fast.(CVE-2025-38102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()\n\nUpdate struct hid_descriptor to better reflect the mandatory and\noptional parts of the HID Descriptor as per USB HID 1.11 specification.\nNote: the kernel currently does not parse any optional HID class\ndescriptors, only the mandatory report descriptor.\n\nUpdate all references to member element desc[0] to rpt_desc.\n\nAdd test to verify bLength and bNumDescriptors values are valid.\n\nReplace the for loop with direct access to the mandatory HID class\ndescriptor member for the report descriptor. This eliminates the\npossibility of getting an out-of-bounds fault.\n\nAdd a warning message if the HID descriptor contains any unsupported\noptional HID class descriptors.(CVE-2025-38103)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mdiobus: Fix potential out-of-bounds read/write access\n\nWhen using publicly available tools like 'mdio-tools' to read/write data\nfrom/to network interface and its PHY via mdiobus, there is no verification of\nparameters passed to the ioctl and it accepts any mdio address.\nCurrently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,\nbut it is possible to pass higher value than that via ioctl.\nWhile read/write operation should generally fail in this case,\nmdiobus provides stats array, where wrong address may allow out-of-bounds\nread/write.\n\nFix that by adding address verification before read/write operation.\nWhile this excludes this access from any statistics, it improves security of\nread/write operation.(CVE-2025-38111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoftware node: Correct a OOB check in software_node_get_reference_args()\n\nsoftware_node_get_reference_args() wants to get @index-th element, so\nthe property value requires at least '(index + 1) * sizeof(*ref)' bytes\nbut that can not be guaranteed by current OOB check, and may cause OOB\nfor malformed property.\n\nFix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.(CVE-2025-38342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: upper bound check of tree index in dbAllocAG\n\nWhen computing the tree index in dbAllocAG, we never check if we are\nout of bounds realative to the size of the stree.\nThis could happen in a scenario where the filesystem metadata are\ncorrupted.(CVE-2025-38697)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: fix null pointer access\n\nWriting a string without delimiters (' ', '\\n', '\\0') to the under\ngpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile\nwill result in a null pointer dereference.(CVE-2025-38705)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()\n\nWhen the volume header contains erroneous values that do not reflect\nthe actual state of the filesystem, hfsplus_fill_super() assumes that\nthe attributes file is not yet created, which later results in hitting\nBUG_ON() when hfsplus_create_attributes_file() is called. Replace this\nBUG_ON() with -EIO error with a message to suggest running fsck tool.(CVE-2025-38712)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()\n\nThe hfsplus_readdir() method is capable to crash by calling\nhfsplus_uni2asc():\n\n[  667.121659][ T9805] ==================================================================\n[  667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10\n[  667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805\n[  667.124578][ T9805]\n[  667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)\n[  667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[  667.124890][ T9805] Call Trace:\n[  667.124893][ T9805]  <TASK>\n[  667.124896][ T9805]  dump_stack_lvl+0x10e/0x1f0\n[  667.124911][ T9805]  print_report+0xd0/0x660\n[  667.124920][ T9805]  ? __virt_addr_valid+0x81/0x610\n[  667.124928][ T9805]  ? __phys_addr+0xe8/0x180\n[  667.124934][ T9805]  ? hfsplus_uni2asc+0x902/0xa10\n[  667.124942][ T9805]  kasan_report+0xc6/0x100\n[  667.124950][ T9805]  ? hfsplus_uni2asc+0x902/0xa10\n[  667.124959][ T9805]  hfsplus_uni2asc+0x902/0xa10\n[  667.124966][ T9805]  ? hfsplus_bnode_read+0x14b/0x360\n[  667.124974][ T9805]  hfsplus_readdir+0x845/0xfc0\n[  667.124984][ T9805]  ? __pfx_hfsplus_readdir+0x10/0x10\n[  667.124994][ T9805]  ? stack_trace_save+0x8e/0xc0\n[  667.125008][ T9805]  ? iterate_dir+0x18b/0xb20\n[  667.125015][ T9805]  ? trace_lock_acquire+0x85/0xd0\n[  667.125022][ T9805]  ? lock_acquire+0x30/0x80\n[  667.125029][ T9805]  ? iterate_dir+0x18b/0xb20\n[  667.125037][ T9805]  ? down_read_killable+0x1ed/0x4c0\n[  667.125044][ T9805]  ? putname+0x154/0x1a0\n[  667.125051][ T9805]  ? __pfx_down_read_killable+0x10/0x10\n[  667.125058][ T9805]  ? apparmor_file_permission+0x239/0x3e0\n[  667.125069][ T9805]  iterate_dir+0x296/0xb20\n[  667.125076][ T9805]  __x64_sys_getdents64+0x13c/0x2c0\n[  667.125084][ T9805]  ? __pfx___x64_sys_getdents64+0x10/0x10\n[  667.125091][ T9805]  ? __x64_sys_openat+0x141/0x200\n[  667.125126][ T9805]  ? __pfx_filldir64+0x10/0x10\n[  667.125134][ T9805]  ? do_user_addr_fault+0x7fe/0x12f0\n[  667.125143][ T9805]  do_syscall_64+0xc9/0x480\n[  667.125151][ T9805]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[  667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9\n[  667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48\n[  667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9\n[  667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9\n[  667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004\n[  667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110\n[  667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260\n[  667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[  667.125207][ T9805]  </TASK>\n[  667.125210][ T9805]\n[  667.145632][ T9805] Allocated by task 9805:\n[  667.145991][ T9805]  kasan_save_stack+0x20/0x40\n[  667.146352][ T9805]  kasan_save_track+0x14/0x30\n[  667.146717][ T9805]  __kasan_kmalloc+0xaa/0xb0\n[  667.147065][ T9805]  __kmalloc_noprof+0x205/0x550\n[  667.147448][ T9805]  hfsplus_find_init+0x95/0x1f0\n[  667.147813][ T9805]  hfsplus_readdir+0x220/0xfc0\n[  667.148174][ T9805]  iterate_dir+0x296/0xb20\n[  667.148549][ T9805]  __x64_sys_getdents64+0x13c/0x2c0\n[  667.148937][ T9805]  do_syscall_64+0xc9/0x480\n[  667.149291][ T9805]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[  667.149809][ T9805]\n[  667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000\n[  667.150030][ T9805]  which belongs to the cache kmalloc-2k of size 2048\n[  667.151282][ T9805] The buggy address is located 0 bytes to the right of\n[  667.151282][ T9805]  allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)\n[  667.1\n---truncated---(CVE-2025-38713)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()\n\nThe hfsplus_bnode_read() method can trigger the issue:\n\n[  174.852007][ T9784] ==================================================================\n[  174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360\n[  174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784\n[  174.854059][ T9784]\n[  174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)\n[  174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[  174.854286][ T9784] Call Trace:\n[  174.854289][ T9784]  <TASK>\n[  174.854292][ T9784]  dump_stack_lvl+0x10e/0x1f0\n[  174.854305][ T9784]  print_report+0xd0/0x660\n[  174.854315][ T9784]  ? __virt_addr_valid+0x81/0x610\n[  174.854323][ T9784]  ? __phys_addr+0xe8/0x180\n[  174.854330][ T9784]  ? hfsplus_bnode_read+0x2f4/0x360\n[  174.854337][ T9784]  kasan_report+0xc6/0x100\n[  174.854346][ T9784]  ? hfsplus_bnode_read+0x2f4/0x360\n[  174.854354][ T9784]  hfsplus_bnode_read+0x2f4/0x360\n[  174.854362][ T9784]  hfsplus_bnode_dump+0x2ec/0x380\n[  174.854370][ T9784]  ? __pfx_hfsplus_bnode_dump+0x10/0x10\n[  174.854377][ T9784]  ? hfsplus_bnode_write_u16+0x83/0xb0\n[  174.854385][ T9784]  ? srcu_gp_start+0xd0/0x310\n[  174.854393][ T9784]  ? __mark_inode_dirty+0x29e/0xe40\n[  174.854402][ T9784]  hfsplus_brec_remove+0x3d2/0x4e0\n[  174.854411][ T9784]  __hfsplus_delete_attr+0x290/0x3a0\n[  174.854419][ T9784]  ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10\n[  174.854427][ T9784]  ? __pfx___hfsplus_delete_attr+0x10/0x10\n[  174.854436][ T9784]  ? __asan_memset+0x23/0x50\n[  174.854450][ T9784]  hfsplus_delete_all_attrs+0x262/0x320\n[  174.854459][ T9784]  ? __pfx_hfsplus_delete_all_attrs+0x10/0x10\n[  174.854469][ T9784]  ? rcu_is_watching+0x12/0xc0\n[  174.854476][ T9784]  ? __mark_inode_dirty+0x29e/0xe40\n[  174.854483][ T9784]  hfsplus_delete_cat+0x845/0xde0\n[  174.854493][ T9784]  ? __pfx_hfsplus_delete_cat+0x10/0x10\n[  174.854507][ T9784]  hfsplus_unlink+0x1ca/0x7c0\n[  174.854516][ T9784]  ? __pfx_hfsplus_unlink+0x10/0x10\n[  174.854525][ T9784]  ? down_write+0x148/0x200\n[  174.854532][ T9784]  ? __pfx_down_write+0x10/0x10\n[  174.854540][ T9784]  vfs_unlink+0x2fe/0x9b0\n[  174.854549][ T9784]  do_unlinkat+0x490/0x670\n[  174.854557][ T9784]  ? __pfx_do_unlinkat+0x10/0x10\n[  174.854565][ T9784]  ? __might_fault+0xbc/0x130\n[  174.854576][ T9784]  ? getname_flags.part.0+0x1c5/0x550\n[  174.854584][ T9784]  __x64_sys_unlink+0xc5/0x110\n[  174.854592][ T9784]  do_syscall_64+0xc9/0x480\n[  174.854600][ T9784]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[  174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167\n[  174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08\n[  174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057\n[  174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167\n[  174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50\n[  174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40\n[  174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0\n[  174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[  174.854658][ T9784]  </TASK>\n[  174.854661][ T9784]\n[  174.879281][ T9784] Allocated by task 9784:\n[  174.879664][ T9784]  kasan_save_stack+0x20/0x40\n[  174.880082][ T9784]  kasan_save_track+0x14/0x30\n[  174.880500][ T9784]  __kasan_kmalloc+0xaa/0xb0\n[  174.880908][ T9784]  __kmalloc_noprof+0x205/0x550\n[  174.881337][ T9784]  __hfs_bnode_create+0x107/0x890\n[  174.881779][ T9784]  hfsplus_bnode_find+0x2d0/0xd10\n[  174.882222][ T9784]  hfsplus_brec_find+0x2b0/0x520\n[  174.882659][ T9784]  hfsplus_delete_all_attrs+0x23b/0x3\n---truncated---(CVE-2025-38714)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/buffer: fix use-after-free when call bh_read() helper\n\nThere's issue as follows:\nBUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110\nRead of size 8 at addr ffffc9000168f7f8 by task swapper/3/0\nCPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n <IRQ>\n dump_stack_lvl+0x55/0x70\n print_address_description.constprop.0+0x2c/0x390\n print_report+0xb4/0x270\n kasan_report+0xb8/0xf0\n end_buffer_read_sync+0xe3/0x110\n end_bio_bh_io_sync+0x56/0x80\n blk_update_request+0x30a/0x720\n scsi_end_request+0x51/0x2b0\n scsi_io_completion+0xe3/0x480\n ? scsi_device_unbusy+0x11e/0x160\n blk_complete_reqs+0x7b/0x90\n handle_softirqs+0xef/0x370\n irq_exit_rcu+0xa5/0xd0\n sysvec_apic_timer_interrupt+0x6e/0x90\n </IRQ>\n\n Above issue happens when do ntfs3 filesystem mount, issue may happens\n as follows:\n           mount                            IRQ\nntfs_fill_super\n  read_cache_page\n    do_read_cache_folio\n      filemap_read_folio\n        mpage_read_folio\n\t do_mpage_readpage\n\t  ntfs_get_block_vbo\n\t   bh_read\n\t     submit_bh\n\t     wait_on_buffer(bh);\n\t                            blk_complete_reqs\n\t\t\t\t     scsi_io_completion\n\t\t\t\t      scsi_end_request\n\t\t\t\t       blk_update_request\n\t\t\t\t        end_bio_bh_io_sync\n\t\t\t\t\t end_buffer_read_sync\n\t\t\t\t\t  __end_buffer_read_notouch\n\t\t\t\t\t   unlock_buffer\n\n            wait_on_buffer(bh);--> return will return to caller\n\n\t\t\t\t\t  put_bh\n\t\t\t\t\t    --> trigger stack-out-of-bounds\nIn the mpage_read_folio() function, the stack variable 'map_bh' is\npassed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and\nwait_on_buffer() returns to continue processing, the stack variable\nis likely to be reclaimed. Consequently, during the end_buffer_read_sync()\nprocess, calling put_bh() may result in stack overrun.\n\nIf the bh is not allocated on the stack, it belongs to a folio.  Freeing\na buffer head which belongs to a folio is done by drop_buffers() which\nwill fail to free buffers which are still locked.  So it is safe to call\nput_bh() before __end_buffer_read_notouch().(CVE-2025-39691)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()\n\nA soft lockup warning was observed on a relative small system x86-64\nsystem with 16 GB of memory when running a debug kernel with kmemleak\nenabled.\n\n  watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]\n\nThe test system was running a workload with hot unplug happening in\nparallel.  Then kemleak decided to disable itself due to its inability to\nallocate more kmemleak objects.  The debug kernel has its\nCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.\n\nThe soft lockup happened in kmemleak_do_cleanup() when the existing\nkmemleak objects were being removed and deleted one-by-one in a loop via a\nworkqueue.  In this particular case, there are at least 40,000 objects\nthat need to be processed and given the slowness of a debug kernel and the\nfact that a raw_spinlock has to be acquired and released in\n__delete_object(), it could take a while to properly handle all these\nobjects.\n\nAs kmemleak has been disabled in this case, the object removal and\ndeletion process can be further optimized as locking isn't really needed. \nHowever, it is probably not worth the effort to optimize for such an edge\ncase that should rarely happen.  So the simple solution is to call\ncond_resched() at periodic interval in the iteration loop to avoid soft\nlockup.(CVE-2025-39737)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: use array_index_nospec with indices that come from guest\n\nmin and dest_id are guest-controlled indices. Using array_index_nospec()\nafter the bounds checks clamps these values to mitigate speculative execution\nside-channels.(CVE-2025-39823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: fix OOB read/write in network-coding decode\n\nbatadv_nc_skb_decode_packet() trusts coded_len and checks only against\nskb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing\npayload headroom, and the source skb length is not verified, allowing an\nout-of-bounds read and a small out-of-bounds write.\n\nValidate that coded_len fits within the payload area of both destination\nand source sk_buffs before XORing.(CVE-2025-39839)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: virtio_uml: Fix use-after-free after put_device in probe\n\nWhen register_virtio_device() fails in virtio_uml_probe(),\nthe code sets vu_dev->registered = 1 even though\nthe device was not successfully registered.\nThis can lead to use-after-free or other issues.(CVE-2025-39951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add max boundary check for VF filters\n\nThere is no check for max filters that VF can request. Add it.(CVE-2025-39968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Fix Use-after-free in validation\n\nNodes stored in the validation duplicates hashtable come from an arena\nallocator that is cleared at the end of vmw_execbuf_process. All nodes\nare expected to be cleared in vmw_validation_drop_ht but this node escaped\nbecause its resource was destroyed prematurely.(CVE-2025-40111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npid: Add a judgment for ns null in pid_nr_ns\n\n__task_pid_nr_ns\n        ns = task_active_pid_ns(current);\n        pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns);\n                if (pid && ns->level <= pid->level) {\n\nSometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.\n\nFor example:\n\tUnable to handle kernel NULL pointer dereference at virtual address 0000000000000058\n\tMem abort info:\n\tESR = 0x0000000096000007\n\tEC = 0x25: DABT (current EL), IL = 32 bits\n\tSET = 0, FnV = 0\n\tEA = 0, S1PTW = 0\n\tFSC = 0x07: level 3 translation fault\n\tData abort info:\n\tISV = 0, ISS = 0x00000007, ISS2 = 0x00000000\n\tCM = 0, WnR = 0, TnD = 0, TagAccess = 0\n\tGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n\tuser pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000\n\t[0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000\n\tpstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\n\tpc : __task_pid_nr_ns+0x74/0xd0\n\tlr : __task_pid_nr_ns+0x24/0xd0\n\tsp : ffffffc08001bd10\n\tx29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001\n\tx26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31\n\tx23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0\n\tx20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000\n\tx17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc\n\tx14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800\n\tx11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001\n\tx8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449\n\tx5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc\n\tx2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0\n\tCall trace:\n\t__task_pid_nr_ns+0x74/0xd0\n\t...\n\t__handle_irq_event_percpu+0xd4/0x284\n\thandle_irq_event+0x48/0xb0\n\thandle_fasteoi_irq+0x160/0x2d8\n\tgeneric_handle_domain_irq+0x44/0x60\n\tgic_handle_irq+0x4c/0x114\n\tcall_on_irq_stack+0x3c/0x74\n\tdo_interrupt_handler+0x4c/0x84\n\tel1_interrupt+0x34/0x58\n\tel1h_64_irq_handler+0x18/0x24\n\tel1h_64_irq+0x68/0x6c\n\taccount_kernel_stack+0x60/0x144\n\texit_task_stack_account+0x1c/0x80\n\tdo_exit+0x7e4/0xaf8\n\t...\n\tget_signal+0x7bc/0x8d8\n\tdo_notify_resume+0x128/0x828\n\tel0_svc+0x6c/0x70\n\tel0t_64_sync_handler+0x68/0xbc\n\tel0t_64_sync+0x1a8/0x1ac\n\tCode: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69)\n\t---[ end trace 0000000000000000 ]---\n\tKernel panic - not syncing: Oops: Fatal exception in interrupt(CVE-2025-40178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: sg: Do not sleep in atomic context\n\nsg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may\nsleep. Hence, call sg_finish_rem_req() with interrupts enabled instead\nof disabled.(CVE-2025-40259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()\n\nIf the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we\nattempt to dereference it in tcm_loop_tpg_address_show() we will get a\nsegfault, see below for an example. So, check tl_hba->sh before\ndereferencing it.\n\n  Unable to allocate struct scsi_host\n  BUG: kernel NULL pointer dereference, address: 0000000000000194\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] PREEMPT SMP NOPTI\n  CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1\n  Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024\n  RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]\n...\n  Call Trace:\n   <TASK>\n   configfs_read_iter+0x12d/0x1d0 [configfs]\n   vfs_read+0x1b5/0x300\n   ksys_read+0x6f/0xf0\n...(CVE-2025-68229)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: core: Protect regulator_supply_alias_list with regulator_list_mutex\n\nregulator_supply_alias_list was accessed without any locking in\nregulator_supply_alias(), regulator_register_supply_alias(), and\nregulator_unregister_supply_alias(). Concurrent registration,\nunregistration and lookups can race, leading to:\n\n1 use-after-free if an alias entry is removed while being read,\n2 duplicate entries when two threads register the same alias,\n3 inconsistent alias mappings observed by consumers.\n\nProtect all traversals, insertions and deletions on\nregulator_supply_alias_list with the existing regulator_list_mutex.(CVE-2025-68354)\n\nA use-after-free vulnerability exists in the mlxsw spectrum multicast route component of Linux Kernel. The vulnerability occurs when updating multicast route statistics, where an instance of list entry deletion during route replace was missed from mutex protection, potentially leading to use-after-free.(CVE-2025-68800)\n\nA reference counting management vulnerability exists in the mlxsw: spectrum_router driver component of the Linux kernel. The driver stores a pointer to a neighbour object without properly holding a reference to it. A reference is only taken when the neighbour is used by a nexthop. This inconsistent reference counting scheme can lead to a situation where, under specific conditions (e.g., during network device event handling), the driver attempts to access a neighbour object that has already been freed, triggering a use-after-free error. An attacker could potentially exploit this vulnerability to cause a kernel crash, thereby affecting system availability.(CVE-2025-68801)\n\nAn off-by-one vulnerability exists in the Intel Ethernet Virtual Function (iavf) driver of the Linux kernel. The flaw resides in the `iavf_config_rss_reg()` function. When configuring the Receive Side Scaling (RSS) hash key and lookup table, incorrect loop boundary conditions (using `<=` instead of `<`) lead to out-of-bounds reads from allocated memory and potential out-of-bounds writes to device registers. An attacker could potentially exploit this vulnerability to cause kernel information disclosure, system instability, or crashes.(CVE-2025-71087)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the e1000 network driver's e1000_tbi_should_accept() function. The function reads the last byte of the frame via 'data[length - 1]' to evaluate the TBI (Tunnel Bypass Identifier) workaround. If the descriptor-reported length is zero or larger than the actual RX buffer size, this read goes out of bounds and can hit unrelated slab objects. The issue is observed from the NAPI receive path (e1000_clean_rx_irq). The root cause is that the TBI check unconditionally dereferences the last byte without validating the reported length first. The fix rejects the frame early if the length is zero or exceeds adapter->rx_buffer_len, preserving the TBI workaround semantics for valid frames and preventing touching memory beyond the RX buffer.(CVE-2025-71093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer\n\nWhen advancing the target expiration for the guest's APIC timer in periodic\nmode, set the expiration to "now" if the target expiration is in the past\n(similar to what is done in update_target_expiration()).  Blindly adding\nthe period to the previous target expiration can result in KVM generating\na practically unbounded number of hrtimer IRQs due to programming an\nexpired timer over and over.  In extreme scenarios, e.g. if userspace\npauses/suspends a VM for an extended duration, this can even cause hard\nlockups in the host.\n\nCurrently, the bug only affects Intel CPUs when using the hypervisor timer\n(HV timer), a.k.a. the VMX preemption timer.  Unlike the software timer,\na.k.a. hrtimer, which KVM keeps running even on exits to userspace, the\nHV timer only runs while the guest is active.  As a result, if the vCPU\ndoes not run for an extended duration, there will be a huge gap between\nthe target expiration and the current time the vCPU resumes running.\nBecause the target expiration is incremented by only one period on each\ntimer expiration, this leads to a series of timer expirations occurring\nrapidly after the vCPU/VM resumes.\n\nMore critically, when the vCPU first triggers a periodic HV timer\nexpiration after resuming, advancing the expiration by only one period\nwill result in a target expiration in the past.  As a result, the delta\nmay be calculated as a negative value.  When the delta is converted into\nan absolute value (tscdeadline is an unsigned u64), the resulting value\ncan overflow what the HV timer is capable of programming.  I.e. the large\nvalue will exceed the VMX Preemption Timer's maximum bit width of\ncpu_preemption_timer_multi + 32, and thus cause KVM to switch from the\nHV timer to the software timer (hrtimers).\n\nAfter switching to the software timer, periodic timer expiration callbacks\nmay be executed consecutively within a single clock interrupt handler,\nbecause hrtimers honors KVM's request for an expiration in the past and\nimmediately re-invokes KVM's callback after reprogramming.  And because\nthe interrupt handler runs with IRQs disabled, restarting KVM's hrtimer\nover and over until the target expiration is advanced to "now" can result\nin a hard lockup.\n\nE.g. the following hard lockup was triggered in the host when running a\nWindows VM (only relevant because it used the APIC timer in periodic mode)\nafter resuming the VM from a long suspend (in the host).\n\n  NMI watchdog: Watchdog detected hard LOCKUP on cpu 45\n  ...\n  RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]\n  ...\n  RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046\n  RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc\n  RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500\n  RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0\n  R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0\n  R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8\n  FS:  00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0\n  PKRU: 55555554\n  Call Trace:\n   <IRQ>\n   apic_timer_fn+0x31/0x50 [kvm]\n   __hrtimer_run_queues+0x100/0x280\n   hrtimer_interrupt+0x100/0x210\n   ? ttwu_do_wakeup+0x19/0x160\n   smp_apic_timer_interrupt+0x6a/0x130\n   apic_timer_interrupt+0xf/0x20\n   </IRQ>\n\nMoreover, if the suspend duration of the virtual machine is not long enough\nto trigger a hard lockup in this scenario, since commit 98c25ead5eda\n("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVM\nwill continue using the software timer until the guest reprograms the APIC\ntimer in some way.  Since the periodic timer does not require frequent APIC\ntimer register programming, the guest may continue to use the software\ntimer in \n---truncated---(CVE-2025-71104)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Do not register unsupported perf events\n\nSynthetic events currently do not have a function to register perf events.\nThis leads to calling the tracepoint register functions with a NULL\nfunction pointer which triggers:\n\n ------------[ cut here ]------------\n WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272\n Modules linked in: kvm_intel kvm irqbypass\n CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\n RIP: 0010:tracepoint_add_func+0x357/0x370\n Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f\n RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246\n RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000\n RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8\n RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780\n R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a\n R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78\n FS:  00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0\n Call Trace:\n  <TASK>\n  tracepoint_probe_register+0x5d/0x90\n  synth_event_reg+0x3c/0x60\n  perf_trace_event_init+0x204/0x340\n  perf_trace_init+0x85/0xd0\n  perf_tp_event_init+0x2e/0x50\n  perf_try_init_event+0x6f/0x230\n  ? perf_event_alloc+0x4bb/0xdc0\n  perf_event_alloc+0x65a/0xdc0\n  __se_sys_perf_event_open+0x290/0x9f0\n  do_syscall_64+0x93/0x7b0\n  ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  ? trace_hardirqs_off+0x53/0xc0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nInstead, have the code return -ENODEV, which doesn't warn and has perf\nerror out with:\n\n # perf record -e synthetic:futex_wait\nError:\nThe sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait).\n"dmesg | grep -i perf" may provide additional information.\n\nIdeally perf should support synthetic events, but for now just fix the\nwarning. The support can come later.(CVE-2025-71125)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-299.0.0.202.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm","kernel-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm","perf-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-299.0.0.202.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm","kernel-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm","perf-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1275"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49157"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50583"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50737"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53680"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53794"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-54263"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37740"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37768"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38051"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38102"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38103"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38111"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38342"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38697"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38705"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38712"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38713"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38714"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39691"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39737"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39823"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39839"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39951"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39968"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40111"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40178"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40259"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68229"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68354"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68800"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68801"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71087"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71093"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71104"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71125"}],"database_specific":{"severity":"High"}}