The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ext4: update sjournalinum if it changes after journal replay

When mounting a crafted ext4 image, sjournalinum may change after journal replay, which is obviously unreasonable because we have successfully loaded and replayed the journal through the old sjournalinum. And the new sjournalinum bypasses some of the checks in ext4getjournal(), which may trigger a null pointer dereference problem. So if sjournalinum changes after the journal replay, we ignore the change, and rewrite the current journal_inum to the superblock.(CVE-2023-53091)

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

scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write

During the sysfs firmware write process, a use-after-free read warning is logged from the lpfcwrobject() routine:

BUG: KFENCE: use-after-free read in lpfcwrobject+0x235/0x310 [lpfc] Use-after-free read at 0x0000000000cf164d (in kfence-#111): lpfcwrobject+0x235/0x310 [lpfc] lpfcwritefirmware.cold+0x206/0x30d [lpfc] lpfcsli4requestfirmwareupdate+0xa6/0x100 [lpfc] lpfcrequestfirmwareupgradestore+0x66/0xb0 [lpfc] kernfsfopwriteiter+0x121/0x1b0 newsyncwrite+0x11c/0x1b0 vfswrite+0x1ef/0x280 ksyswrite+0x5f/0xe0 dosyscall64+0x59/0x90 entrySYSCALL64after_hwframe+0x63/0xcd

The driver accessed wr_object pointer data, which was initialized into mailbox payload memory, after the mailbox object was released back to the mailbox pool.

Fix by moving the mailbox free calls to the end of the routine ensuring that we don't reference internal mailbox memory after release.(CVE-2023-53282)

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

startkernel: Add _nostackprotector function attribute

Back during the discussion of commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try") we discussed the need for a function attribute to control the omission of stack protectors on a per-function basis; at the time Clang had support for nostackprotector but GCC did not. This was fixed in gcc-11. Now that the function attribute is available, let's start using it.

Callers of bootinitstackcanary need to use this function attribute unless they're compiled with -fno-stack-protector, otherwise the canary stored in the stack slot of the caller will differ upon the call to bootinitstackcanary. This will lead to a call to _stackchk_fail() then panic.(CVE-2023-53491)

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

Bluetooth: Fix hcisuspendsync crash

If hciunregisterdev() frees the hcidev object but hcisuspendnotifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hcisuspendsync+0x109/0x301 [bluetooth] <4>[102152.653259] hcisuspenddev+0x78/0xcd [bluetooth] <4>[102152.653263] hcisuspendnotifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifiercallchain+0x43/0x6b <4>[102152.653271] _blockingnotifiercallchain+0x48/0x69 <4>[102152.653273] _pmnotifiercallchain+0x22/0x39 <4>[102152.653276] pmsuspend+0x287/0x57c <4>[102152.653278] statestore+0xae/0xe5 <4>[102152.653281] kernfsfopwrite+0x109/0x173 <4>[102152.653284] _vfswrite+0x16f/0x1a2 <4>[102152.653287] ? selinuxfilepermission+0xca/0x16f <4>[102152.653289] ? securityfilepermission+0x36/0x109 <4>[102152.653291] vfswrite+0x114/0x21d <4>[102152.653293] _x64syswrite+0x7b/0xdb <4>[102152.653296] dosyscall64+0x59/0x194 <4>[102152.653299] entrySYSCALL64after_hwframe+0x5c/0xc1

This patch holds the reference count of the hcidev object while processing it in hcisuspend_notifier to avoid potential crash caused by the race condition.(CVE-2023-53520)

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

Bluetooth: hci_event: call disconnect callback before deleting conn

In hcicsdisconnect, we do hciconndel even if disconnection failed.

ISO, L2CAP and SCO connections refer to the hciconn without hciconnget, so disconncfm must be called so they can clean up their conn, otherwise use-after-free occurs.

ISO:

isosockconnect:880: sk 00000000eabd6557 isoconnectcis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da ... isoconnadd:140: hcon 000000001696f1fd conn 00000000b6251073 hcidevput:1487: hci0 orig refcnt 17 _isochanadd:214: conn 00000000b6251073 isosockcleartimer:117: sock 00000000eabd6557 state 3 ... hcirxwork:4085: hci0 Event packet hcieventpacket:7601: hci0: event 0x0f hcicmdstatusevt:4346: hci0: opcode 0x0406 hcicsdisconnect:2760: hci0: status 0x0c hcisentcmddata:3107: hci0 opcode 0x0406 hciconndel:1151: hci0 hcon 000000001696f1fd handle 2560 hciconnunlink:1102: hci0: hcon 000000001696f1fd hciconndrop:1451: hcon 00000000d8521aaf orig refcnt 2 hcichanlistflush:2780: hcon 000000001696f1fd hcidevput:1487: hci0 orig refcnt 21 hcidevput:1487: hci0 orig refcnt 20 hcireqcmdcomplete:3978: opcode 0x0406 status 0x0c ... <no iso* activity on sk/conn> ... isosock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557 BUG: kernel NULL pointer dereference, address: 0000000000000668 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014

RIP: 0010:isosocksendmsg (net/bluetooth/iso.c:1112) bluetooth

L2CAP:

hcicmdstatusevt:4359: hci0: opcode 0x0406 hcicsdisconnect:2760: hci0: status 0x0c hcisentcmddata:3085: hci0 opcode 0x0406 hciconndel:1151: hci0 hcon ffff88800c999000 handle 3585 hciconnunlink:1102: hci0: hcon ffff88800c999000 hcichanlistflush:2780: hcon ffff88800c999000 hcichandel:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280 ... BUG: KASAN: slab-use-after-free in hcisend_acl+0x2d/0x540 [bluetooth] Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175

CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x5b/0x90 printreport+0xcf/0x670 ? virtaddrvalid+0xf8/0x180 ? hcisendacl+0x2d/0x540 [bluetooth] kasanreport+0xa8/0xe0 ? hcisendacl+0x2d/0x540 [bluetooth] hcisendacl+0x2d/0x540 [bluetooth] ? _pfxlockacquire+0x10/0x10 l2capchansend+0x1fd/0x1300 [bluetooth] ? l2capsocksendmsg+0xf2/0x170 [bluetooth] ? pfxl2capchansend+0x10/0x10 [bluetooth] ? lockrelease+0x1d5/0x3c0 ? markheldlocks+0x1a/0x90 l2capsocksendmsg+0x100/0x170 [bluetooth] sockwriteiter+0x275/0x280 ? _pfxsockwriteiter+0x10/0x10 ? _pfxlockacquire+0x10/0x10 doiterreadvwritev+0x176/0x220 ? _pfxdoiterreadvwritev+0x10/0x10 ? findheldlock+0x83/0xa0 ? selinuxfilepermission+0x13e/0x210 doiterwrite+0xda/0x340 vfswritev+0x1b4/0x400 ? _pfxvfswritev+0x10/0x10 ? _seccompfilter+0x112/0x750 ? populateseccompdata+0x182/0x220 ? _fgetlight+0xdf/0x100 ? dowritev+0x19d/0x210 dowritev+0x19d/0x210 ? _pfxdowritev+0x10/0x10 ? markheldlocks+0x1a/0x90 dosyscall64+0x60/0x90 ? lockdephardirqsonprepare+0x149/0x210 ? dosyscall64+0x6c/0x90 ? lockdephardirqsonprepare+0x149/0x210 entrySYSCALL64afterhwframe+0x72/0xdc RIP: 0033:0x7ff45cb23e64 Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIGRAX: 0000000000000014 RAX: ffffffffffffffda RBX: ---truncated---(CVE-2023-53673)

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

iio: adc: rockchip_saradc: fix information leak in triggered buffer

The 'data' local struct is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iioforeachactivechannel() to assign new values.

Initialize the struct to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57907)

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

iio: dummy: iiosimplydummy_buffer: fix information leak in triggered buffer

The 'data' array is allocated via kmalloc() and it is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iioforeachactivechannel() to assign new values.

Use kzalloc for the memory allocation to avoid pushing uninitialized information to userspace.(CVE-2024-57911)

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

memory: tegra20-emc: fix an OF node reference bug in tegraemcfindnodebyramcode()

As offindnodebyname() release the reference of the argument device node, tegraemcfindnodebyramcode() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the "emc-tables" node is always device's child node with the property "nvidia,use-ram-code", and the "lpddr2" node is a child of the "emc-tables" node. Thus utilize the foreachchildofnode() macro and ofgetchildbyname() instead of offindnodebyname() to simplify the code.

This bug was found by an experimental verification tool that I am developing.

krzysztof: applied v1, adjust the commit msg to incorporate v2 parts

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

wifi: iwlwifi: limit printed string from FW file

There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.

Fix that by limiting the print format to the size of the buffer we have.(CVE-2025-21905)

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

memstick: rtsxusbms: Fix slab-use-after-free in rtsxusbmsdrvremove

This fixes the following crash:

================================================================== BUG: KASAN: slab-use-after-free in rtsxusbmspollcard+0x159/0x200 [rtsxusbms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241

CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNEDMODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsxusbmspollcard [rtsxusbms] Call Trace: <TASK> dumpstacklvl+0x51/0x70 printaddressdescription.constprop.0+0x27/0x320 ? rtsxusbmspollcard+0x159/0x200 [rtsxusbms] printreport+0x3e/0x70 kasanreport+0xab/0xe0 ? rtsxusbmspollcard+0x159/0x200 [rtsxusbms] rtsxusbmspollcard+0x159/0x200 [rtsxusbms] ? pfxrtsxusbmspollcard+0x10/0x10 [rtsxusbms] ? _pfxschedule+0x10/0x10 ? kickpool+0x3b/0x270 processonework+0x357/0x660 workerthread+0x390/0x4c0 ? _pfxworkerthread+0x10/0x10 kthread+0x190/0x1d0 ? _pfxkthread+0x10/0x10 retfromfork+0x2d/0x50 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 161446: kasansavestack+0x20/0x40 kasansavetrack+0x10/0x30 _kasankmalloc+0x7b/0x90 _kmallocnoprof+0x1a7/0x470 memstickallochost+0x1f/0xe0 [memstick] rtsxusbmsdrvprobe+0x47/0x320 [rtsxusbms] platformprobe+0x60/0xe0 calldriverprobe+0x35/0x120 reallyprobe+0x123/0x410 _driverprobedevice+0xc7/0x1e0 driverprobedevice+0x49/0xf0 _deviceattachdriver+0xc6/0x160 busforeachdrv+0xe4/0x160 _deviceattach+0x13a/0x2b0 busprobedevice+0xbd/0xd0 deviceadd+0x4a5/0x760 platformdeviceadd+0x189/0x370 mfdadddevice+0x587/0x5e0 mfdadddevices+0xb1/0x130 rtsxusbprobe+0x28e/0x2e0 [rtsxusb] usbprobeinterface+0x15c/0x460 calldriverprobe+0x35/0x120 reallyprobe+0x123/0x410 _driverprobedevice+0xc7/0x1e0 driverprobedevice+0x49/0xf0 _deviceattachdriver+0xc6/0x160 busforeachdrv+0xe4/0x160 _deviceattach+0x13a/0x2b0 rebindmarkedinterfaces.isra.0+0xcc/0x110 usbresetdevice+0x352/0x410 usbdevdoioctl+0xe5c/0x1860 usbdevioctl+0xa/0x20 _x64sysioctl+0xc5/0xf0 dosyscall64+0x59/0x170 entrySYSCALL64after_hwframe+0x76/0x7e

Freed by task 161506: kasansavestack+0x20/0x40 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x36/0x60 _kasanslabfree+0x34/0x50 kfree+0x1fd/0x3b0 devicerelease+0x56/0xf0 kobjectcleanup+0x73/0x1c0 rtsxusbmsdrvremove+0x13d/0x220 [rtsxusbms] platformremove+0x2f/0x50 devicereleasedriverinternal+0x24b/0x2e0 busremovedevice+0x124/0x1d0 devicedel+0x239/0x530 platformdevicedel.part.0+0x19/0xe0 platformdeviceunregister+0x1c/0x40 mfdremovedevicesfn+0x167/0x170 deviceforeachchildreverse+0xc9/0x130 mfdremovedevices+0x6e/0xa0 rtsxusbdisconnect+0x2e/0xd0 [rtsxusb] usbunbindinterface+0xf3/0x3f0 devicereleasedriverinternal+0x24b/0x2e0 procdisconnectclaim+0x13d/0x220 usbdevdoioctl+0xb5e/0x1860 usbdevioctl+0xa/0x20 _x64sysioctl+0xc5/0xf0 dosyscall64+0x59/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

Last potentially related work creation: kasansavestack+0x20/0x40 kasanrecordauxstack+0x85/0x90 insertwork+0x29/0x100 _queuework+0x34a/0x540 calltimerfn+0x2a/0x160 expiretimers+0x5f/0x1f0 _runtimerbase.part.0+0x1b6/0x1e0 runtimersoftirq+0x8b/0xe0 handlesoftirqs+0xf9/0x360 _irqexitrcu+0x114/0x130 sysvecapictimerinterrupt+0x72/0x90 asmsysvecapictimer_interrupt+0x16/0x20

Second to last potentially related work creation: kasansavestack+0x20/0x40 kasanrecordauxstack+0x85/0x90 insertwork+0x29/0x100 _queuework+0x34a/0x540 calltimerfn+0x2a/0x160 expiretimers+0x5f/0x1f0 _runtimerbase.part.0+0x1b6/0x1e0 runtimersoftirq+0x8b/0xe0 handle_softirqs+0xf9/0x ---truncated---(CVE-2025-22020)

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

usb: xhci: Apply the link chain quirk on NEC isoc endpoints

Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment:

[ 1.041954] xhcihcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhcihcd: AMD-Vi: Event logged [IOPAGEFAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhcihcd: AMD-Vi: Event logged [IOPAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]

It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.

[ 7.041671] xhcihcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhcihcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhcihcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhcihcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhcihcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 31 [ 7.042144] xhcihcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhcihcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 31 [ 7.042266] xhcihcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820

At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.

[ 7.098130] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 13 [ 7.098132] xhcihcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 13 [ 7.098256] xhcihcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2

It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain.

Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board.

[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhcihcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVEROK cmdage=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 physseg 5 prio class 0

Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set.

The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times.

No ne ---truncated---(CVE-2025-22022)

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

ksmbd: fix overflow in dacloffset bounds check

The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smbcheckpermdacl() and smbinherit_dacl().

This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer.

This patch converts dacloffset to unsigned int and uses checkaddoverflow() to validate access to the DACL.(CVE-2025-22039)

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

vhost-scsi: Fix handling of multiple calls to vhostscsiset_endpoint

If vhostscsisetendpoint is called multiple times without a vhostscsiclearendpoint between them, we can hit multiple bugs found by Haoran Zhang:

1. Use-after-free when no tpgs are found:

This fixes a use after free that occurs when vhostscsisetendpoint is called more than once and calls after the first call do not find any tpgs to add to the vstpg. When vhostscsisetendpoint first finds tpgs to add to the vstpg array match=true, so we will do:

vhostvqsetbackend(vq, vstpg); ...

kfree(vs->vstpg); vs->vstpg = vs_tpg;

If vhostscsisetendpoint is called again and no tpgs are found match=false so we skip the vhostvqsetbackend call leaving the pointer to the vs_tpg we then free via:

kfree(vs->vstpg); vs->vstpg = vs_tpg;

If a scsi request is then sent we do:

vhostscsihandlevq -> vhostscsigetreq -> vhostvqget_backend

which sees the vs_tpg we just did a kfree on.

2. Tpg dir removal hang:

This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1.

The problem is that if vhostscsisetendpoint detects a tpg is already in the vs->vstpg array or if the tpg has been removed so targetdependitem fails, the undepend goto handler will do targetundependitem on all tpgs in the vstpg array dropping their refcount to 0. At this time vstpg contains both the tpgs we have added in the current vhostscsisetendpoint call as well as tpgs we added in previous calls which are also in vs->vstpg.

Later, when vhostscsiclearendpoint runs it will do targetundependitem on all the tpgs in the vs->vstpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir.

3. Tpg leak:

This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhostscsiset_endpoint is called multiple times but with different target names.

The bug occurs if a user has called VHOSTSCSISETENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOSTSCSISETENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vstpg array. Later when we do vhostscsiclearendpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vstpg. We will then return from the function without doing targetundepend_item on the tpgs.

Because of all these bugs, it looks like being able to call vhostscsisetendpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhostscsisetendpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhostscsiclear_endpoint first.(CVE-2025-22083)

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

ext4: fix off-by-one error in do_split

Syzkaller detected a use-after-free issue in ext4insertdentry that was caused by out-of-bounds access due to incorrect splitting in do_split.

BUG: KASAN: use-after-free in ext4insertdentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847

CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 kasancheckrange+0x282/0x290 mm/kasan/generic.c:189 _asanmemcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4insertdentry+0x36a/0x6d0 fs/ext4/namei.c:2109 adddirenttobuf+0x3d9/0x750 fs/ext4/namei.c:2154 makeindexeddir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4addentry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4addnondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfssymlink+0x137/0x2e0 fs/namei.c:4615 dosymlinkat+0x222/0x3a0 fs/namei.c:4641 _dosyssymlink fs/namei.c:4662 [inline] _sesyssymlink fs/namei.c:4660 [inline] _x64syssymlink+0x7a/0x90 fs/namei.c:4660 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f </TASK>

The following loop is located right above 'if' statement.

for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; }

'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)

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

media: venus: hfi: add check to handle incorrect queue size

qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, emptyspace will be bigger than the space actually available. Since newwridx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->qsize

if (wridx >= rdidx) emptyspace = qsize - (wridx - rdidx) .... if (newwridx < qsize) { memcpy(wrptr, packet, dwords << 2) --> OOB write

Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)

In the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on pppsynctxmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When pppsynctxmung receives an incoming package with an emptypayload:(remote) gef➤ p *(struct pppoehdr *) (skb->head + skb->networkheader)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4 , data = 0xffff88803346f416 : 377 , truesize = 0x380, len = 0x0, datalen = 0x0, maclen = 0xe, hdr_len = 0x0,it is not safe to access data[2].[(CVE-2025-37749)

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

ext4: fix OOB read when checking dotdot dir

Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).

ext4emptydir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4checkdirentry() and then uses its reclen member to compute the location of '..' dir entry (in ext4nextentry). It assumes the '..' dir entry fits into the same data block.

If the reclen of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4direntry2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4checkdir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.

Fix this by extending _ext4checkdirentry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).

Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.

This issue was found by syzkaller tool.

Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in ext4checkdirentry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dumpstacklvl+0xa7/0xd0 [ 38.595325] printaddressdescription.constprop.0+0x2c/0x3f0 [ 38.595339] ? _ext4checkdirentry+0x67e/0x710 [ 38.595349] printreport+0xaa/0x250 [ 38.595359] ? _ext4checkdirentry+0x67e/0x710 [ 38.595368] ? kasanaddrtoslab+0x9/0x90 [ 38.595378] kasanreport+0xab/0xe0 [ 38.595389] ? _ext4checkdirentry+0x67e/0x710 [ 38.595400] _ext4checkdirentry+0x67e/0x710 [ 38.595410] ext4emptydir+0x465/0x990 [ 38.595421] ? _pfxext4emptydir+0x10/0x10 [ 38.595432] ext4rmdir.part.0+0x29a/0xd10 [ 38.595441] ? _dquotinitialize+0x2a7/0xbf0 [ 38.595455] ? _pfxext4rmdir.part.0+0x10/0x10 [ 38.595464] ? _pfxdquotinitialize+0x10/0x10 [ 38.595478] ? downwrite+0xdb/0x140 [ 38.595487] ? _pfxdownwrite+0x10/0x10 [ 38.595497] ext4rmdir+0xee/0x140 [ 38.595506] vfsrmdir+0x209/0x670 [ 38.595517] ? lookuponeqstrexcl+0x3b/0x190 [ 38.595529] dormdir+0x363/0x3c0 [ 38.595537] ? _pfxdormdir+0x10/0x10 [ 38.595544] ? strncpyfromuser+0x1ff/0x2e0 [ 38.595561] _x64sysunlinkat+0xf0/0x130 [ 38.595570] dosyscall64+0x5b/0x180 [ 38.595583] entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2025-37785)

In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt s not safe to access nlalen(ovskey) if the data is smaller thanthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)

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

iommu/amd: Fix potential buffer overflow in parseivrsacpihid

There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIIDLEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIIDLEN + 1 but uid string will overflow uid buffer which size is 256.

The same applies to the hid string with length 13 and uid string with length 250.

Check the length of hid and uid strings separately to prevent buffer overflow.

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

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

netfilter: nftsetpipapo: clamp maximum map bucket size to INT_MAX

Otherwise, it is possible to hit WARNONONCE in _kvmallocnodenoprof() when resizing hashtable because _GFP_NOWARN is unset.

Similar to:

b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")(CVE-2025-38201)

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

bpf: Fix WARN() in getbpfrawtpregs

syzkaller reported an issue:

WARNING: CPU: 3 PID: 5971 at kernel/trace/bpftrace.c:1861 getbpfrawtpregs+0xa4/0x100 kernel/trace/bpftrace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:getbpfrawtpregs+0xa4/0x100 kernel/trace/bpftrace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> bpfgetstackrawtp kernel/trace/bpftrace.c:1934 [inline] bpfgetstackrawtp+0x24/0x160 kernel/trace/bpftrace.c:1931 bpfprogec3b2eefa702d8d3+0x43/0x47 bpfdispatchernopfunc include/linux/bpf.h:1316 [inline] _bpfprogrun include/linux/filter.h:718 [inline] bpfprogrun include/linux/filter.h:725 [inline] _bpftracerun kernel/trace/bpftrace.c:2363 [inline] bpftracerun3+0x23f/0x5a0 kernel/trace/bpftrace.c:2405 _bpftracemmaplockacquirereturned+0xfc/0x140 include/trace/events/mmaplock.h:47 _traceitermmaplockacquirereturned+0x79/0xc0 include/trace/events/mmaplock.h:47 _dotracemmaplockacquirereturned include/trace/events/mmaplock.h:47 [inline] tracemmaplockacquirereturned include/trace/events/mmaplock.h:47 [inline] _mmaplockdotraceacquirereturned+0x138/0x1f0 mm/mmaplock.c:35 _mmaplocktraceacquirereturned include/linux/mmaplock.h:36 [inline] mmapreadtrylock include/linux/mmaplock.h:204 [inline] stackmapgetbuildidoffset+0x535/0x6f0 kernel/bpf/stackmap.c:157 _bpfgetstack+0x307/0xa10 kernel/bpf/stackmap.c:483 _bpfgetstack kernel/bpf/stackmap.c:499 [inline] bpfgetstack+0x32/0x40 kernel/bpf/stackmap.c:496 _bpfgetstackrawtp kernel/trace/bpftrace.c:1941 [inline] bpfgetstackrawtp+0x124/0x160 kernel/trace/bpftrace.c:1931 bpfprog_ec3b2eefa702d8d3+0x43/0x47

Tracepoint like tracemmaplockacquirereturned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARNONONCE will be triggered. As Alexei suggested, remove the WARNONONCE first.(CVE-2025-38285)

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

net/sched: Always pass notifications when child class becomes empty

Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlen_notify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free.

The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free:

tc qdisc add dev lo root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo parent 1: classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1
tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0
tc qdisc add dev lo parent 2:1 handle 3: netem
tc qdisc add dev lo parent 3:1 handle 4: blackhole

echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
tc class delete dev lo classid 1:1
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888

Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisctreereducebacklog always calls qlennotify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdiscreset() and / or qdiscpurgequeue() which ultimately resets its qlen to 0 thus causing the following qdisctreereducebacklog() to report to the parent. Note that this may call qlennotify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlennotify() handlers idempotent.(CVE-2025-38350)

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

smb: client: fix use-after-free in cifsoplockbreak

A race condition can occur in cifsoplockbreak() leading to a use-after-free of the cinode structure when unmounting:

cifsoplockbreak() cifsFileInfoput(cfile) cifsFileInfoputfinal() cifssbdeactive() [last ref, start releasing sb] killsb() killanonsuper() genericshutdownsuper() evictinodes() disposelist() evict() destroyinode() callrcu(&inode->ircu, icallback) spinlock(&cinode->openfilelock) <- OK [later] icallback() cifsfreeinode() kmemcachefree(cinode) spinunlock(&cinode->openfilelock) <- UAF cifsdoneoplock_break(cinode) <- UAF

The issue occurs when umount has already released its reference to the superblock. When cifsFileInfoput() calls cifssbdeactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifsoplockbreak() continues to access the cinode after this point, resulting in use-after-free.

Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.(CVE-2025-38527)

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

net/packet: fix a race in packetsetring() and packet_notifier()

When packetsetring() releases po->bindlock, another thread can run packetnotifier() and process an NETDEV_UP event.

This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packetbind() and packetnotifier()").

There too the packetnotifier NETDEVUP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken.

The po->bindlock in packetsetring and packetnotifier precede the introduction of git history.(CVE-2025-38617)

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

ice: Fix a null pointer dereference in icecopyandinitpkg()

Add check for the return value of devm_kmemdup() to prevent potential null pointer dereference.(CVE-2025-38664)

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

ASoC: core: Check for rtd == NULL in sndsocremovepcmruntime()

sndsocremovepcmruntime() might be called with rtd == NULL which will leads to null pointer dereference. This was reproduced with topology loading and marking a link as ignore due to missing hardware component on the system. On module removal the soctplgremovelink() would call sndsocremovepcm_runtime() with rtd == NULL since the link was ignored, no runtime was created.(CVE-2025-38706)

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

ALSA: usb-audio: Validate UAC3 power domain descriptors, too

UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.(CVE-2025-38729)

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

vxlan: Fix NPD when refreshing an FDB entry with a nexthop object

VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.

However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].

Fix by dropping such packets earlier. Remove the misleading comment from firstremotercu().

[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlansnoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlanencapbypass+0x209/0x240 encapbypassiflocal+0xb1/0x100 vxlanxmitone+0x1375/0x17e0 vxlanxmit+0x6b4/0x15f0 devhardstartxmit+0x5d/0x1c0 _devqueuexmit+0x246/0xfd0 packetsendmsg+0x113a/0x1850 _socksendmsg+0x38/0x70 _syssendto+0x126/0x180 _x64syssendto+0x24/0x30 dosyscall64+0xa4/0x260 entrySYSCALL64after_hwframe+0x4b/0x53

[2] #!/bin/bash

ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo

ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb

ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning

bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10

mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)

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

KVM: arm64: Prevent access to vCPU events before init

Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception.

In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exceptiontargetel() during the next injection:

kernel BUG at arch/arm64/kvm/injectfault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exceptiontargetel+0x88/0x8c lr : pendserrorexception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exceptiontargetel+0x88/0x8c (P) kvminjectserroresr+0x40/0x3b4 _kvmarmvcpusetevents+0xf0/0x100 kvmarchvcpuioctl+0x180/0x9d4 kvmvcpuioctl+0x60c/0x9f4 _arm64sysioctl+0xac/0x104 invokesyscall+0x48/0x110 el0svccommon.constprop.0+0x40/0xe0 doel0svc+0x1c/0x28 el0svc+0x34/0xf0 el0t64synchandler+0xa0/0xe4 el0t64sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)

Reject the ioctls outright as no sane VMM would call these before KVMARMVCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.(CVE-2025-40102)

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

smc: Use _skdstget() and dstdevrcu() in in smcclcprfxset().

smcclcprfx_set() is called during connect() and not under RCU nor RTNL.

Using skdstget(sk)->dev could trigger UAF.

Let's use _skdstget() and devdstrcu() under rcureadlock() after kernelgetsockname().

Note that the returned value of smcclcprfx_set() is not used in the caller.

While at it, we change the 1st arg of smcclcprfxset[46]rcu() not to touch dst there.(CVE-2025-40139)