OESA-2026-1275

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Fix premature hw access after PCI error

After a recoverable PCI error has been detected and recovered, qla driver needs to check to see if the error condition still persist and/or wait for the OS to give the resume signal.

Sep 8 22:26:03 localhost kernel: WARNING: CPU: 9 PID: 124606 at qlatmpl.c:440 qla27xxfwdtentryt266+0x55/0x60 [qla2xxx] Sep 8 22:26:03 localhost kernel: RIP: 0010:qla27xxfwdtentryt266+0x55/0x60 [qla2xxx] Sep 8 22:26:03 localhost kernel: Call Trace: Sep 8 22:26:03 localhost kernel: ? qla27xxwalktemplate+0xb1/0x1b0 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla27xxexecutefwdttemplate+0x12a/0x160 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla27xxfwdump+0xa0/0x1c0 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla2xxxpcimmioenabled+0xfb/0x120 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? reportmmioenabled+0x44/0x80 Sep 8 22:26:03 localhost kernel: ? reportslotreset+0x80/0x80 Sep 8 22:26:03 localhost kernel: ? pciwalkbus+0x70/0x90 Sep 8 22:26:03 localhost kernel: ? aerdevcorrectableshow+0xc0/0xc0 Sep 8 22:26:03 localhost kernel: ? pciedorecovery+0x1bb/0x240 Sep 8 22:26:03 localhost kernel: ? aerrecoverworkfunc+0xaa/0xd0 Sep 8 22:26:03 localhost kernel: ? processonework+0x1a7/0x360 .. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-8041:22: detected PCI disconnect. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: qla27xxfwdtentry_t262: dump ram MB failed. Area 5h start 198013h end 198013h Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: Unable to capture FW dump Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-1015:22: cmd=0x0, waited 5221 msecs Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-680d:22: mmio enabled returning. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-d04c:22: MBX Command timeout for cmd 0, iocontrol=ffffffff jiffies=10140f2e5 mb[0-3]=0xffff 0xffff 0xffff 0xffff

In the Linux kernel, the following vulnerability has been resolved:

md/raid0, raid10: Don't set discard sectors for request queue

It should use diskstacklimits to get a proper maxdiscardsectors rather than setting a value by stack drivers.

And there is a bug. If all member disks are rotational devices, raid0/raid10 set maxdiscardsectors. So the member devices are not ssd/nvme, but raid0/raid10 export the wrong value. It reports warning messages in function _blkdevissue_discard when mkfs.xfs like this:

[ 4616.022599] ------------[ cut here ]------------ [ 4616.027779] WARNING: CPU: 4 PID: 99634 at block/blk-lib.c:50 blkdevissuediscard+0x16a/0x1a0 [ 4616.140663] RIP: 0010:blkdevissuediscard+0x16a/0x1a0 [ 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 [ 4616.167567] RSP: 0018:ffffaab88cbffca8 EFLAGS: 00010246 [ 4616.173406] RAX: ffff9ba1f9e44678 RBX: 0000000000000000 RCX: ffff9ba1c9792080 [ 4616.181376] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ba1c9792080 [ 4616.189345] RBP: 0000000000000cc0 R08: ffffaab88cbffd10 R09: 0000000000000000 [ 4616.197317] R10: 0000000000000012 R11: 0000000000000000 R12: 0000000000000000 [ 4616.205288] R13: 0000000000400000 R14: 0000000000000cc0 R15: ffff9ba1c9792080 [ 4616.213259] FS: 00007f9a5534e980(0000) GS:ffff9ba1b7c80000(0000) knlGS:0000000000000000 [ 4616.222298] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4616.228719] CR2: 000055a390a4c518 CR3: 0000000123e40006 CR4: 00000000001706e0 [ 4616.236689] Call Trace: [ 4616.239428] blkdevissuediscard+0x52/0xb0 [ 4616.244108] blkdevcommonioctl+0x43c/0xa00 [ 4616.248883] blkdevioctl+0x116/0x280 [ 4616.252977] _x64sysioctl+0x8a/0xc0 [ 4616.257163] dosyscall64+0x5c/0x90 [ 4616.261164] ? handlemmfault+0xc5/0x2a0 [ 4616.265652] ? douseraddrfault+0x1d8/0x690 [ 4616.270527] ? dosyscall64+0x69/0x90 [ 4616.274717] ? excpagefault+0x62/0x150 [ 4616.279097] entrySYSCALL64after_hwframe+0x63/0xcd [ 4616.284748] RIP: 0033:0x7f9a55398c6b(CVE-2022-50583)

In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Validate index root when initialize NTFS security

This enhances the sanity check for $SDH and $SII while initializing NTFS security, guarantees these index root are legit.

[ 162.459513] BUG: KASAN: use-after-free in hdrfinde.isra.0+0x10c/0x320 [ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243 [ 162.460851] [ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42 [ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 162.462609] Call Trace: [ 162.462954] <TASK> [ 162.463276] dumpstacklvl+0x49/0x63 [ 162.463822] printreport.cold+0xf5/0x689 [ 162.464608] ? unwindgetreturnaddress+0x3a/0x60 [ 162.465766] ? hdrfinde.isra.0+0x10c/0x320 [ 162.466975] kasanreport+0xa7/0x130 [ 162.467506] ? _rawspinlockirq+0xc0/0xf0 [ 162.467998] ? hdrfinde.isra.0+0x10c/0x320 [ 162.468536] _asanload2+0x68/0x90 [ 162.468923] hdrfinde.isra.0+0x10c/0x320 [ 162.469282] ? cmpuints+0xe0/0xe0 [ 162.469557] ? cmpsdh+0x90/0x90 [ 162.469864] ? nifindattr+0x214/0x300 [ 162.470217] ? niloadmi+0x80/0x80 [ 162.470479] ? entrySYSCALL64afterhwframe+0x63/0xcd [ 162.470931] ? ntfsbreadrun+0x190/0x190 [ 162.471307] ? indxgetroot+0xe4/0x190 [ 162.471556] ? indxgetroot+0x140/0x190 [ 162.471833] ? indxinit+0x1e0/0x1e0 [ 162.472069] ? fndclear+0x115/0x140 [ 162.472363] ? rawspinlockirqsave+0x100/0x100 [ 162.472731] indxfind+0x184/0x470 [ 162.473461] ? sysvecapictimerinterrupt+0x57/0xc0 [ 162.474429] ? indxfindbuffer+0x2d0/0x2d0 [ 162.474704] ? dosyscall64+0x3b/0x90 [ 162.474962] dirsearchu+0x196/0x2f0 [ 162.475381] ? ntfsnlstoutf16+0x450/0x450 [ 162.475661] ? ntfssecurityinit+0x3d6/0x440 [ 162.475906] ? issdvalid+0x180/0x180 [ 162.476191] ntfsextendinit+0x13f/0x2c0 [ 162.476496] ? ntfsfixpostread+0x130/0x130 [ 162.476861] ? iput.part.0+0x286/0x320 [ 162.477325] ntfsfillsuper+0x11e0/0x1b50 [ 162.477709] ? putntfs+0x1d0/0x1d0 [ 162.477970] ? vsprintf+0x20/0x20 [ 162.478258] ? setblocksize+0x95/0x150 [ 162.478538] gettreebdev+0x232/0x370 [ 162.478789] ? putntfs+0x1d0/0x1d0 [ 162.479038] ntfsfsgettree+0x15/0x20 [ 162.479374] vfsgettree+0x4c/0x130 [ 162.479729] pathmount+0x654/0xfe0 [ 162.480124] ? putname+0x80/0xa0 [ 162.480484] ? finishautomount+0x2e0/0x2e0 [ 162.480894] ? putname+0x80/0xa0 [ 162.481467] ? kmemcachefree+0x1c4/0x440 [ 162.482280] ? putname+0x80/0xa0 [ 162.482714] domount+0xd6/0xf0 [ 162.483264] ? pathmount+0xfe0/0xfe0 [ 162.484782] ? _kasancheckwrite+0x14/0x20 [ 162.485593] _x64sysmount+0xca/0x110 [ 162.486024] dosyscall64+0x3b/0x90 [ 162.486543] entrySYSCALL64afterhwframe+0x63/0xcd [ 162.487141] RIP: 0033:0x7f9d374e948a [ 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 [ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5 [ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a [ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0 [ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020 [ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0 [ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff [ 162.493644] </TASK> [ 162.493908] [ 162.494214] The buggy address belongs to the physical page: [ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc [ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) [ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000 [ 162.498928] raw: 0000000000000000 0000000000240000 0 ---truncated---(CVE-2022-50737)

In the Linux kernel, the following vulnerability has been resolved:

NFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGAL

OPDESC() simply indexes into nfsd4_ops[] by the op's operation number, without range checking that value. It assumes callers are careful to avoid calling it with an out-of-bounds opnum value.

nfsd4decodecompound() is not so careful, and can invoke OPDESC() with opnum set to OPILLEGAL, which is 10044 -- well beyond the end of nfsd4ops[].(CVE-2023-53680)

In the Linux kernel, the following vulnerability has been resolved:

cifs: fix session state check in reconnect to avoid use-after-free issue

Don't collect exiting session in smb2reconnectserver(), because it will be released soon.

Note that the exiting session will stay in server->smbseslist until it complete the cifsfreeipc() and logoff() and then delete itself from the list.(CVE-2023-53794)

In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau/kms/nv50-: init hpdirqlock for PIOR DP

Fixes OOPS on boards with ANX9805 DP encoders.(CVE-2023-54263)

In the Linux kernel, the following vulnerability has been resolved:

jfs: add sanity check for agwidth in dbMount

The width in dmapctl of the AG is zero, it trigger a divide error when calculating the control page level in dbAllocAG.

To avoid this issue, add a check for agwidth in dbAllocAG.(CVE-2025-37740)

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: Prevent division by zero

The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37768)

In the Linux kernel, the following vulnerability has been resolved:

smb: client: Fix use-after-free in cifsfilldirent

There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning.

================================================================== BUG: KASAN: slab-use-after-free in cifsfilldirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975

CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x53/0x70 printreport+0xce/0x640 kasanreport+0xb8/0xf0 cifsfilldirent+0xb03/0xb60 [cifs] cifsreaddir+0x12cb/0x3190 [cifs] iteratedir+0x1a1/0x520 _x64sysgetdents+0x134/0x220 dosyscall64+0x4b/0x110 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff 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 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIGRAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 </TASK>

Allocated by task 408: kasansavestack+0x20/0x40 kasansavetrack+0x14/0x30 _kasanslaballoc+0x6e/0x70 kmemcacheallocnoprof+0x117/0x3d0 mempoolallocnoprof+0xf2/0x2c0 cifsbufget+0x36/0x80 [cifs] allocatebuffers+0x1d2/0x330 [cifs] cifsdemultiplexthread+0x22b/0x2690 [cifs] kthread+0x394/0x720 retfromfork+0x34/0x70 retfromforkasm+0x1a/0x30

Freed by task 342979: kasansavestack+0x20/0x40 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 _kasanslabfree+0x37/0x50 kmemcachefree+0x2b8/0x500 cifsbufrelease+0x3c/0x70 [cifs] cifsreaddir+0x1c97/0x3190 [cifs] iteratedir+0x1a1/0x520 _x64sysgetdents64+0x134/0x220 dosyscall64+0x4b/0x110 entrySYSCALL64after_hwframe+0x76/0x7e

The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entiremapcount:0 nrpagesmapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) pagetype: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================

POC is available in the link [1].

The problem triggering process is as follows:

Process 1 Process 2

---truncated---(CVE-2025-38051)

In the Linux kernel, the following vulnerability has been resolved:

VMCI: fix race between vmcihostsetupnotify and vmcictxunsetnotify

During our test, it is found that a warning can be trigger in trygrabfolio as follow:

------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 trygrabfolio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:trygrabfolio+0x106/0x130 Call Trace: <TASK> followhugepmd+0x240/0x8e0 followpmdmask.constprop.0.isra.0+0x40b/0x5c0 followpudmask.constprop.0.isra.0+0x14a/0x170 followpagemask+0x1c2/0x1f0 _getuserpages+0x176/0x950 _guplongtermlocked+0x15b/0x1060 ? gupfast+0x120/0x1f0 gupfastfallback+0x17e/0x230 getuserpagesfast+0x5f/0x80 vmcihostunlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]---

Digging into the source, context->notifypage may init by getuserpagesfast and can be seen in vmcictxunsetnotify which will try to putpage. However getuserpagesfast is not finished here and lead to following trygrab_folio warning. The race condition is shown as follow:

cpu0 cpu1 vmcihostdosetnotify vmcihostsetupnotify getuserpagesfast(uva, 1, FOLLWRITE, &context->notifypage); locklesspagesfrommm guppgdrange guphugepmd // update &context->notifypage vmcihostdosetnotify vmcictxunsetnotify notifypage = context->notifypage; if (notifypage) putpage(notifypage); // page is freed _guplongtermlocked _getuserpages followtranshugepmd trygrab_folio // warn here

To slove this, use local variable page to make notifypage can be seen after finish getuserpagesfast.(CVE-2025-38102)

In the Linux kernel, the following vulnerability has been resolved:

HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()

Update struct hid_descriptor to better reflect the mandatory and optional parts of the HID Descriptor as per USB HID 1.11 specification. Note: the kernel currently does not parse any optional HID class descriptors, only the mandatory report descriptor.

Update all references to member element desc[0] to rpt_desc.

Add test to verify bLength and bNumDescriptors values are valid.

Replace the for loop with direct access to the mandatory HID class descriptor member for the report descriptor. This eliminates the possibility of getting an out-of-bounds fault.

Add a warning message if the HID descriptor contains any unsupported optional HID class descriptors.(CVE-2025-38103)

In the Linux kernel, the following vulnerability has been resolved:

net/mdiobus: Fix potential out-of-bounds read/write access

When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHYMAXADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write.

Fix that by adding address verification before read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.(CVE-2025-38111)

In the Linux kernel, the following vulnerability has been resolved:

software node: Correct a OOB check in softwarenodegetreferenceargs()

softwarenodegetreferenceargs() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property.

Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.(CVE-2025-38342)

In the Linux kernel, the following vulnerability has been resolved:

jfs: upper bound check of tree index in dbAllocAG

When computing the tree index in dbAllocAG, we never check if we are out of bounds realative to the size of the stree. This could happen in a scenario where the filesystem metadata are corrupted.(CVE-2025-38697)

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: fix null pointer access

Writing a string without delimiters (' ', '\n', '\0') to the under gpuod/fanctrl sysfs or pppowerprofile_mode for the CUSTOM profile will result in a null pointer dereference.(CVE-2025-38705)

In the Linux kernel, the following vulnerability has been resolved:

hfsplus: don't use BUGON() in hfspluscreateattributesfile()

When the volume header contains erroneous values that do not reflect the actual state of the filesystem, hfsplusfillsuper() assumes that the attributes file is not yet created, which later results in hitting BUGON() when hfspluscreateattributesfile() is called. Replace this BUG_ON() with -EIO error with a message to suggest running fsck tool.(CVE-2025-38712)

In the Linux kernel, the following vulnerability has been resolved:

hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()

The hfsplusreaddir() method is capable to crash by calling hfsplusuni2asc():

[ 667.121659][ T9805] ================================================================== [ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplusuni2asc+0x902/0xa10 [ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805 [ 667.124578][ T9805] [ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full) [ 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 [ 667.124890][ T9805] Call Trace: [ 667.124893][ T9805] <TASK> [ 667.124896][ T9805] dumpstacklvl+0x10e/0x1f0 [ 667.124911][ T9805] printreport+0xd0/0x660 [ 667.124920][ T9805] ? virtaddrvalid+0x81/0x610 [ 667.124928][ T9805] ? _physaddr+0xe8/0x180 [ 667.124934][ T9805] ? hfsplusuni2asc+0x902/0xa10 [ 667.124942][ T9805] kasanreport+0xc6/0x100 [ 667.124950][ T9805] ? hfsplusuni2asc+0x902/0xa10 [ 667.124959][ T9805] hfsplusuni2asc+0x902/0xa10 [ 667.124966][ T9805] ? hfsplusbnoderead+0x14b/0x360 [ 667.124974][ T9805] hfsplusreaddir+0x845/0xfc0 [ 667.124984][ T9805] ? _pfxhfsplusreaddir+0x10/0x10 [ 667.124994][ T9805] ? stacktracesave+0x8e/0xc0 [ 667.125008][ T9805] ? iteratedir+0x18b/0xb20 [ 667.125015][ T9805] ? tracelockacquire+0x85/0xd0 [ 667.125022][ T9805] ? lockacquire+0x30/0x80 [ 667.125029][ T9805] ? iteratedir+0x18b/0xb20 [ 667.125037][ T9805] ? downreadkillable+0x1ed/0x4c0 [ 667.125044][ T9805] ? putname+0x154/0x1a0 [ 667.125051][ T9805] ? _pfxdownreadkillable+0x10/0x10 [ 667.125058][ T9805] ? apparmorfilepermission+0x239/0x3e0 [ 667.125069][ T9805] iteratedir+0x296/0xb20 [ 667.125076][ T9805] _x64sysgetdents64+0x13c/0x2c0 [ 667.125084][ T9805] ? _pfxx64sysgetdents64+0x10/0x10 [ 667.125091][ T9805] ? _x64sysopenat+0x141/0x200 [ 667.125126][ T9805] ? _pfxfilldir64+0x10/0x10 [ 667.125134][ T9805] ? douseraddrfault+0x7fe/0x12f0 [ 667.125143][ T9805] dosyscall64+0xc9/0x480 [ 667.125151][ T9805] entrySYSCALL64afterhwframe+0x77/0x7f [ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9 [ 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 [ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIGRAX: 00000000000000d9 [ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9 [ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004 [ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110 [ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260 [ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 667.125207][ T9805] </TASK> [ 667.125210][ T9805] [ 667.145632][ T9805] Allocated by task 9805: [ 667.145991][ T9805] kasansavestack+0x20/0x40 [ 667.146352][ T9805] kasansavetrack+0x14/0x30 [ 667.146717][ T9805] _kasankmalloc+0xaa/0xb0 [ 667.147065][ T9805] _kmallocnoprof+0x205/0x550 [ 667.147448][ T9805] hfsplusfindinit+0x95/0x1f0 [ 667.147813][ T9805] hfsplusreaddir+0x220/0xfc0 [ 667.148174][ T9805] iteratedir+0x296/0xb20 [ 667.148549][ T9805] _x64sysgetdents64+0x13c/0x2c0 [ 667.148937][ T9805] dosyscall64+0xc9/0x480 [ 667.149291][ T9805] entrySYSCALL64after_hwframe+0x77/0x7f [ 667.149809][ T9805] [ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000 [ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048 [ 667.151282][ T9805] The buggy address is located 0 bytes to the right of [ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c) [ 667.1 ---truncated---(CVE-2025-38713)

In the Linux kernel, the following vulnerability has been resolved:

hfsplus: fix slab-out-of-bounds in hfsplusbnoderead()

The hfsplusbnoderead() method can trigger the issue:

[ 174.852007][ T9784] ================================================================== [ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplusbnoderead+0x2f4/0x360 [ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784 [ 174.854059][ T9784] [ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full) [ 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 [ 174.854286][ T9784] Call Trace: [ 174.854289][ T9784] <TASK> [ 174.854292][ T9784] dumpstacklvl+0x10e/0x1f0 [ 174.854305][ T9784] printreport+0xd0/0x660 [ 174.854315][ T9784] ? virtaddrvalid+0x81/0x610 [ 174.854323][ T9784] ? _physaddr+0xe8/0x180 [ 174.854330][ T9784] ? hfsplusbnoderead+0x2f4/0x360 [ 174.854337][ T9784] kasanreport+0xc6/0x100 [ 174.854346][ T9784] ? hfsplusbnoderead+0x2f4/0x360 [ 174.854354][ T9784] hfsplusbnoderead+0x2f4/0x360 [ 174.854362][ T9784] hfsplusbnodedump+0x2ec/0x380 [ 174.854370][ T9784] ? _pfxhfsplusbnodedump+0x10/0x10 [ 174.854377][ T9784] ? hfsplusbnodewriteu16+0x83/0xb0 [ 174.854385][ T9784] ? srcugpstart+0xd0/0x310 [ 174.854393][ T9784] ? _markinodedirty+0x29e/0xe40 [ 174.854402][ T9784] hfsplusbrecremove+0x3d2/0x4e0 [ 174.854411][ T9784] _hfsplusdeleteattr+0x290/0x3a0 [ 174.854419][ T9784] ? _pfxhfsfind1strecbycnid+0x10/0x10 [ 174.854427][ T9784] ? _pfxhfsplusdeleteattr+0x10/0x10 [ 174.854436][ T9784] ? _asanmemset+0x23/0x50 [ 174.854450][ T9784] hfsplusdeleteallattrs+0x262/0x320 [ 174.854459][ T9784] ? _pfxhfsplusdeleteallattrs+0x10/0x10 [ 174.854469][ T9784] ? rcuiswatching+0x12/0xc0 [ 174.854476][ T9784] ? _markinodedirty+0x29e/0xe40 [ 174.854483][ T9784] hfsplusdeletecat+0x845/0xde0 [ 174.854493][ T9784] ? _pfxhfsplusdeletecat+0x10/0x10 [ 174.854507][ T9784] hfsplusunlink+0x1ca/0x7c0 [ 174.854516][ T9784] ? _pfxhfsplusunlink+0x10/0x10 [ 174.854525][ T9784] ? downwrite+0x148/0x200 [ 174.854532][ T9784] ? _pfxdownwrite+0x10/0x10 [ 174.854540][ T9784] vfsunlink+0x2fe/0x9b0 [ 174.854549][ T9784] dounlinkat+0x490/0x670 [ 174.854557][ T9784] ? _pfxdounlinkat+0x10/0x10 [ 174.854565][ T9784] ? _mightfault+0xbc/0x130 [ 174.854576][ T9784] ? getnameflags.part.0+0x1c5/0x550 [ 174.854584][ T9784] _x64sysunlink+0xc5/0x110 [ 174.854592][ T9784] dosyscall64+0xc9/0x480 [ 174.854600][ T9784] entrySYSCALL64afterhwframe+0x77/0x7f [ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167 [ 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 [ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIGRAX: 0000000000000057 [ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167 [ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50 [ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40 [ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0 [ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 174.854658][ T9784] </TASK> [ 174.854661][ T9784] [ 174.879281][ T9784] Allocated by task 9784: [ 174.879664][ T9784] kasansavestack+0x20/0x40 [ 174.880082][ T9784] kasansavetrack+0x14/0x30 [ 174.880500][ T9784] _kasankmalloc+0xaa/0xb0 [ 174.880908][ T9784] _kmallocnoprof+0x205/0x550 [ 174.881337][ T9784] _hfsbnodecreate+0x107/0x890 [ 174.881779][ T9784] hfsplusbnodefind+0x2d0/0xd10 [ 174.882222][ T9784] hfsplusbrecfind+0x2b0/0x520 [ 174.882659][ T9784] hfsplusdeleteall_attrs+0x23b/0x3 ---truncated---(CVE-2025-38714)

In the Linux kernel, the following vulnerability has been resolved:

fs/buffer: fix use-after-free when call bh_read() helper

There's issue as follows: BUG: KASAN: stack-out-of-bounds in endbufferreadsync+0xe3/0x110 Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0 CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x8664 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <IRQ> dumpstacklvl+0x55/0x70 printaddressdescription.constprop.0+0x2c/0x390 printreport+0xb4/0x270 kasanreport+0xb8/0xf0 endbufferreadsync+0xe3/0x110 endbiobhiosync+0x56/0x80 blkupdaterequest+0x30a/0x720 scsiendrequest+0x51/0x2b0 scsiiocompletion+0xe3/0x480 ? scsideviceunbusy+0x11e/0x160 blkcompletereqs+0x7b/0x90 handlesoftirqs+0xef/0x370 irqexitrcu+0xa5/0xd0 sysvecapictimer_interrupt+0x6e/0x90 </IRQ>

Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQ ntfsfillsuper readcachepage doreadcachefolio filemapreadfolio mpagereadfolio dompagereadpage ntfsgetblockvbo bhread submitbh waitonbuffer(bh); blkcompletereqs scsiiocompletion scsiendrequest blkupdaterequest endbiobhiosync endbufferreadsync _endbufferreadnotouch unlockbuffer

        wait_on_buffer(bh);--> return will return to caller

                  put_bh
                    --> trigger stack-out-of-bounds

In the mpagereadfolio() function, the stack variable 'mapbh' is passed to ntfsgetblockvbo(). Once unlockbuffer() unlocks and waitonbuffer() returns to continue processing, the stack variable is likely to be reclaimed. Consequently, during the endbufferreadsync() process, calling put_bh() may result in stack overrun.

If the bh is not allocated on the stack, it belongs to a folio. Freeing a buffer head which belongs to a folio is done by dropbuffers() which will fail to free buffers which are still locked. So it is safe to call putbh() before _endbufferreadnotouch().(CVE-2025-39691)

In the Linux kernel, the following vulnerability has been resolved:

mm/kmemleak: avoid soft lockup in _kmemleakdo_cleanup()

A soft lockup warning was observed on a relative small system x86-64 system with 16 GB of memory when running a debug kernel with kmemleak enabled.

watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]

The test system was running a workload with hot unplug happening in parallel. Then kemleak decided to disable itself due to its inability to allocate more kmemleak objects. The debug kernel has its CONFIGDEBUGKMEMLEAKMEMPOOL_SIZE set to 40,000.

The soft lockup happened in kmemleakdocleanup() when the existing kmemleak objects were being removed and deleted one-by-one in a loop via a workqueue. In this particular case, there are at least 40,000 objects that need to be processed and given the slowness of a debug kernel and the fact that a rawspinlock has to be acquired and released in _delete_object(), it could take a while to properly handle all these objects.

As kmemleak has been disabled in this case, the object removal and deletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edge case that should rarely happen. So the simple solution is to call cond_resched() at periodic interval in the iteration loop to avoid soft lockup.(CVE-2025-39737)

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: use arrayindexnospec with indices that come from guest

min and destid are guest-controlled indices. Using arrayindex_nospec() after the bounds checks clamps these values to mitigate speculative execution side-channels.(CVE-2025-39823)

In the Linux kernel, the following vulnerability has been resolved:

batman-adv: fix OOB read/write in network-coding decode

batadvncskbdecodepacket() trusts codedlen and checks only against skb->len. XOR starts at sizeof(struct batadvunicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write.

Validate that codedlen fits within the payload area of both destination and source skbuffs before XORing.(CVE-2025-39839)

In the Linux kernel, the following vulnerability has been resolved:

um: virtiouml: Fix use-after-free after putdevice in probe

When registervirtiodevice() fails in virtioumlprobe(), the code sets vu_dev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.(CVE-2025-39951)

In the Linux kernel, the following vulnerability has been resolved:

i40e: add max boundary check for VF filters

There is no check for max filters that VF can request. Add it.(CVE-2025-39968)

In the Linux kernel, the following vulnerability has been resolved:

drm/vmwgfx: Fix Use-after-free in validation

Nodes stored in the validation duplicates hashtable come from an arena allocator that is cleared at the end of vmwexecbufprocess. All nodes are expected to be cleared in vmwvalidationdrop_ht but this node escaped because its resource was destroyed prematurely.(CVE-2025-40111)

In the Linux kernel, the following vulnerability has been resolved:

pid: Add a judgment for ns null in pidnrns

_taskpidnrns ns = taskactivepidns(current); pidnrns(rcudereference(*taskpidptr(task, type)), ns); if (pid && ns->level <= pid->level) {

Sometimes null is returned for taskactivepidns. Then it will trigger kernel panic in pidnr_ns.

For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : _taskpidnrns+0x74/0xd0 lr : _taskpidnrns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: _taskpidnrns+0x74/0xd0 ... _handleirqeventpercpu+0xd4/0x284 handleirqevent+0x48/0xb0 handlefasteoiirq+0x160/0x2d8 generichandledomainirq+0x44/0x60 gichandleirq+0x4c/0x114 callonirqstack+0x3c/0x74 dointerrupthandler+0x4c/0x84 el1interrupt+0x34/0x58 el1h64irqhandler+0x18/0x24 el1h64irq+0x68/0x6c accountkernelstack+0x60/0x144 exittaskstackaccount+0x1c/0x80 doexit+0x7e4/0xaf8 ... getsignal+0x7bc/0x8d8 donotifyresume+0x128/0x828 el0svc+0x6c/0x70 el0t64synchandler+0x68/0xbc el0t64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt(CVE-2025-40178)

In the Linux kernel, the following vulnerability has been resolved:

scsi: sg: Do not sleep in atomic context

sgfinishremreq() calls blkrqunmapuser(). The latter function may sleep. Hence, call sgfinishrem_req() with interrupts enabled instead of disabled.(CVE-2025-40259)

In the Linux kernel, the following vulnerability has been resolved:

scsi: target: tcmloop: Fix segfault in tcmlooptpgaddress_show()

If the allocation of tlhba->sh fails in tcmloopdriverprobe() and we attempt to dereference it in tcmlooptpgaddressshow() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it.

Unable to allocate struct scsihost BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcmlooptpgaddressshow+0x2e/0x50 [tcmloop] ... Call Trace: <TASK> configfsreaditer+0x12d/0x1d0 [configfs] vfsread+0x1b5/0x300 ksys_read+0x6f/0xf0 ...(CVE-2025-68229)

In the Linux kernel, the following vulnerability has been resolved:

regulator: core: Protect regulatorsupplyaliaslist with regulatorlist_mutex

regulatorsupplyaliaslist was accessed without any locking in regulatorsupplyalias(), regulatorregistersupplyalias(), and regulatorunregistersupply_alias(). Concurrent registration, unregistration and lookups can race, leading to:

1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers.

Protect all traversals, insertions and deletions on regulatorsupplyaliaslist with the existing regulatorlist_mutex.(CVE-2025-68354)

A 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)

A 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)

An 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)

In the Linux kernel, a buffer overflow vulnerability exists in the e1000 network driver's e1000tbishouldaccept() 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 (e1000cleanrxirq). 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->rxbufferlen, preserving the TBI workaround semantics for valid frames and preventing touching memory beyond the RX buffer.(CVE-2025-71093)

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer

When advancing the target expiration for the guest's APIC timer in periodic mode, set the expiration to "now" if the target expiration is in the past (similar to what is done in updatetargetexpiration()). Blindly adding the period to the previous target expiration can result in KVM generating a practically unbounded number of hrtimer IRQs due to programming an expired timer over and over. In extreme scenarios, e.g. if userspace pauses/suspends a VM for an extended duration, this can even cause hard lockups in the host.

Currently, the bug only affects Intel CPUs when using the hypervisor timer (HV timer), a.k.a. the VMX preemption timer. Unlike the software timer, a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the HV timer only runs while the guest is active. As a result, if the vCPU does not run for an extended duration, there will be a huge gap between the target expiration and the current time the vCPU resumes running. Because the target expiration is incremented by only one period on each timer expiration, this leads to a series of timer expirations occurring rapidly after the vCPU/VM resumes.

More critically, when the vCPU first triggers a periodic HV timer expiration after resuming, advancing the expiration by only one period will result in a target expiration in the past. As a result, the delta may be calculated as a negative value. When the delta is converted into an absolute value (tscdeadline is an unsigned u64), the resulting value can overflow what the HV timer is capable of programming. I.e. the large value will exceed the VMX Preemption Timer's maximum bit width of cpupreemptiontimer_multi + 32, and thus cause KVM to switch from the HV timer to the software timer (hrtimers).

After switching to the software timer, periodic timer expiration callbacks may be executed consecutively within a single clock interrupt handler, because hrtimers honors KVM's request for an expiration in the past and immediately re-invokes KVM's callback after reprogramming. And because the interrupt handler runs with IRQs disabled, restarting KVM's hrtimer over and over until the target expiration is advanced to "now" can result in a hard lockup.

E.g. the following hard lockup was triggered in the host when running a Windows VM (only relevant because it used the APIC timer in periodic mode) after resuming the VM from a long suspend (in the host).

NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advanceperiodictargetexpiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: <IRQ> apictimerfn+0x31/0x50 [kvm] _hrtimerrunqueues+0x100/0x280 hrtimerinterrupt+0x100/0x210 ? ttwudowakeup+0x19/0x160 smpapictimerinterrupt+0x6a/0x130 apictimerinterrupt+0xf/0x20 </IRQ>

Moreover, if the suspend duration of the virtual machine is not long enough to trigger a hard lockup in this scenario, since commit 98c25ead5eda ("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVM will continue using the software timer until the guest reprograms the APIC timer in some way. Since the periodic timer does not require frequent APIC timer register programming, the guest may continue to use the software timer in ---truncated---(CVE-2025-71104)

In the Linux kernel, the following vulnerability has been resolved:

tracing: Do not register unsupported perf events

Synthetic events currently do not have a function to register perf events. This leads to calling the tracepoint register functions with a NULL function pointer which triggers:

------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepointaddfunc+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvmintel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepointaddfunc+0x357/0x370 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 RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: <TASK> tracepointproberegister+0x5d/0x90 syntheventreg+0x3c/0x60 perftraceeventinit+0x204/0x340 perftraceinit+0x85/0xd0 perftpeventinit+0x2e/0x50 perftryinitevent+0x6f/0x230 ? perfeventalloc+0x4bb/0xdc0 perfeventalloc+0x65a/0xdc0 _sesysperfeventopen+0x290/0x9f0 dosyscall64+0x93/0x7b0 ? entrySYSCALL64afterhwframe+0x76/0x7e ? tracehardirqsoff+0x53/0xc0 entrySYSCALL64after_hwframe+0x76/0x7e

Instead, have the code return -ENODEV, which doesn't warn and has perf error out with:

# perf record -e synthetic:futexwait Error: The sysperfeventopen() syscall returned with 19 (No such device) for event (synthetic:futex_wait). "dmesg | grep -i perf" may provide additional information.

Ideally perf should support synthetic events, but for now just fix the warning. The support can come later.(CVE-2025-71125)