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

iommufd: Break the loop on failure in iommufdfaultfopsread()

On a copytouser() failure inside the inner listforeachentry, only the inner loop breaks; the outer while re-fetches the just-restored fault group and retries the failing copytouser() forever, spinning the reader at 100% CPU with fault->mutex held.

Check rc after the inner loop and break the outer while as well.

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

netfs: Fix zeropoint update where isize > remoteisize

Fix the update of the zero point[] by netfsreleasefolio() when there is uncommitted data in the pagecache beyond the folio being released but the on-server EOF is in this folio (ie. isize > remoteisize). The update needs to limit zeropoint to remoteisize, not isize as isize is a local phenomenon reflecting updates made locally to the pagecache, not stuff written to the server. remoteisize tracks the server's isize.

[] The zero point is the file position from which we can assume that the server will just return zeros, so we can avoid generating reads.

Note that netfsinvalidatefolio() probably doesn't need fixing as zeropoint should be updated by setattr after truncation or fallocate.

Found with:

fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops

using the following as junk.fsxops:

truncate 0x0 0x1bbae 0x82864 write 0x3ef2e 0xf9c8 0x1bbae write 0x67e05 0xcb5a 0x4e8f6 mapread 0x57781 0x85b6 0x7495f copyrange 0x5d3d 0x10329 0x54fac 0x7495f write 0x64710 0x1c2b 0x7495f mapread 0x64000 0x1000 0x7495f

on cifs with the default cache option.

It shows read-gaps on folio 0x64 failing with a short read (ie. it hits EOF) if the FMODEREAD check is commented out in netfsperformwrite():

if (//(file->fmode & FMODEREAD) || netfsiscacheenabled(ctx)) {

and no fscache. This was initially found with the generic/522 xfstest.

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

netfs: Fix partial invalidation of streaming-write folio

In netfsinvalidatefolio(), if the region of a partial invalidation overlaps the front (but not all) of a dirty write cached in a streaming write page (dirty, but not uptodate, with the dirty region tracked by a netfsfolio struct), the function modifies the dirty region - but incorrectly as it moves the region forward by setting the start to the start, not the end, of the invalidation region.

Fix this by setting finfo->dirtyoffset to the end of the invalidation region (iend).

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

wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925txcheckaggr()

Move the NULL check for 'sta' before dereferencing it to prevent a possible crash.

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

net: airoha: Move ndesc initialization at end of airohaqdmainitrxqueue()

If queue entry or DMA descriptor list allocation fails in airohaqdmainitrxqueue routine, airohaqdmacleanup() will trigger a NULL pointer dereference running netifnapidel() for RX queue NAPIs since netifnapiadd() has never been executed to this particular RX NAPI. The issue is due to the early ndesc initialization in airohaqdmainitrxqueue() since airohaqdmacleanup() relies on ndesc value to check if the queue is properly initialized. Fix the issue moving ndesc initialization at end of airohaqdmainittx routine. Move pagepool allocation after descriptor list allocation in order to avoid memory leaks if desc allocation fails.

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

spi: ch341: fix devres lifetime

USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes).

Fix the controller and driver data lifetime so that they are released on driver unbind.

Note that this also makes sure that the SPI controller is placed correctly under the USB interface in the device tree.

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

spi: ch341: fix memory leaks on probe failures

Make sure to deregister the controller, disable pins, and kill and free the RX URB on probe failures to mirror disconnect and avoid memory leaks and use-after-free.

Also add an explicit URB kill on disconnect for symmetry (even if that is not strictly required as USB core would have stopped it in the current setup).

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

crypto: caam - fix netdev memory leak in dpaa2caamprobe

When commit 0e1a4d427f58 ("crypto: caam: Unembed netdev structure in dpaa2") converted embedded netdevice to dynamically allocated pointers, it added cleanup in dpaa2dpsecidisable() but missed adding cleanup in dpaa2dpsecifree() for error paths.

This causes memory leaks when dpaa2dpsecidpiosetup() fails during probe due to DPIO devices not being ready yet. The kernel's deferred probe mechanism handles the retry successfully, but the netdevs allocated during the failed probe attempt are never freed, resulting in kmemleak reports showing multiple leaked netdev-related allocations all traced back to dpaa2caamprobe().

Fix this by preserving the CPU mask of allocated netdevs during setup and using it for cleanup in dpaa2dpsecifree(). This approach ensures that only the CPUs that actually had netdevs allocated will be cleaned up, avoiding potential issues with CPU hotplug scenarios.

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

phy: freescale: imx8qm-hsio: fix NULL pointer dereference

During the probe the refclkpad pointer is set to NULL if the 'fsl,refclk-pad-mode' property is not defined in the devicetree node. But in imxhsioconfigureclkpad() this pointer is unconditionally used which could result in a NULL pointer dereference. So check the pointer before to use it.

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

i3c: dw: Fix memory leak in dwi3cmasteri2cxfers()

The dwi3cmasteri2cxfers() function allocates memory for the xfer structure using dwi3cmasterallocxfer(). If pmruntimeresumeandget() fails, the function returns without freeing the allocated xfer, resulting in a memory leak.

Add a dwi3cmasterfreexfer() call to the error path to ensure the allocated memory is properly freed.

Compile tested only. Issue found using a prototype static analysis tool and code review.

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

net: mscc: ocelot: add missing lock protection in ocelotportxmitinj()

ocelotportxmitinj() calls ocelotcaninject() and ocelotportinjectframe() without holding the injection group lock. Both functions contain lockdepassertheld() for the injection lock, and the correct caller felixportdeferredxmit() properly acquires the lock using ocelotlockinjgrp() before calling these functions.

Add ocelotlockinjgrp()/ocelotunlockinjgrp() around the register injection path to fix the missing lock protection. The FDMA path is not affected as it uses its own locking mechanism.

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

mptcp: pm: in-kernel: always set ID as avail when rm endp

Syzkaller managed to find a combination of actions that was generating this warning:

WARNING: net/mptcp/pmkernel.c:1074 at marksubflowendpavailable net/mptcp/pmkernel.c:1074 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pmkernel.c:1074 at mptcppmnlfullmesh net/mptcp/pmkernel.c:1446 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pmkernel.c:1074 at mptcppmnlsetflagsall net/mptcp/pmkernel.c:1474 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pmkernel.c:1074 at mptcppmnlsetflags+0x5de/0x640 net/mptcp/pmkernel.c:1538, CPU#1: syz.7.48/2535 Modules linked in: CPU: 1 UID: 0 PID: 2535 Comm: syz.7.48 Not tainted 6.18.0-03987-gea5f5e676cf5 #17 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 25.10 PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:marksubflowendpavailable net/mptcp/pmkernel.c:1074 [inline] RIP: 0010:mptcppmnlfullmesh net/mptcp/pmkernel.c:1446 [inline] RIP: 0010:mptcppmnlsetflagsall net/mptcp/pmkernel.c:1474 [inline] RIP: 0010:mptcppmnlsetflags+0x5de/0x640 net/mptcp/pmkernel.c:1538 Code: 89 c7 e8 c5 8c 73 fe e9 f7 fd ff ff 49 83 ef 80 e8 b7 8c 73 fe 4c 89 ff be 03 00 00 00 e8 4a 29 e3 fe eb ac e8 a3 8c 73 fe 90 <0f> 0b 90 e9 3d ff ff ff e8 95 8c 73 fe b8 a1 ff ff ff eb 1a e8 89 RSP: 0018:ffffc9001535b820 EFLAGS: 00010287 netdevsim0: tunchrioctl cmd 1074025677 RAX: ffffffff82da294d RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc900096d0000 RSI: 00000000000006d6 RDI: 00000000000006d7 netdevsim0: linktype set to 823 RBP: ffff88802cdb2240 R08: 00000000000104ae R09: ffffffffffffffff R10: ffffffff82da27d4 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88801246d8c0 R14: ffffc9001535b8b8 R15: ffff88802cdb1800 FS: 00007fc6ac5a76c0(0000) GS:ffff8880f90c8000(0000) knlGS:0000000000000000 netlink: 'syz.3.50': attribute type 5 has an invalid length. CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 netlink: 1232 bytes leftover after parsing attributes in process syz.3.50'. CR2: 0000200000010000 CR3: 0000000025b1a000 CR4: 0000000000350ef0 Call Trace: <TASK> mptcppmsetflags net/mptcp/pmnetlink.c:277 [inline] mptcppmnlsetflagsdoit+0x1d7/0x210 net/mptcp/pmnetlink.c:282 genlfamilyrcvmsgdoit+0x117/0x180 net/netlink/genetlink.c:1115 genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlinkrcvskb+0x16d/0x240 net/netlink/afnetlink.c:2550 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1318 [inline] netlinkunicast+0x3e9/0x4c0 net/netlink/afnetlink.c:1344 netlinksendmsg+0x4ab/0x5b0 net/netlink/afnetlink.c:1894 socksendmsgnosec net/socket.c:718 [inline] socksendmsg+0xc9/0xf0 net/socket.c:733 syssendmsg+0x272/0x3b0 net/socket.c:2608 syssendmsg+0x2de/0x320 net/socket.c:2662 syssendmsg net/socket.c:2694 [inline] dosyssendmsg net/socket.c:2699 [inline] sesyssendmsg net/socket.c:2697 [inline] x64syssendmsg+0x110/0x1a0 net/socket.c:2697 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xed/0x360 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fc6adb66f6d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fc6ac5a6ff8 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fc6addf5fa0 RCX: 00007fc6adb66f6d RDX: 0000000000048084 RSI: 00002000000002c0 RDI: 000000000000000e RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000 ---truncated---

drm/amd/display: Add signal type check for dcn401 getphyd32clksrc

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

soc: qcom: pd-mapper: Fix element length in servreglocpfrreqei

It looks element length declared in servreglocpfrreqei for reason not matching servreglocpfrreq's reason field due which we could observe decoding error on PD crash.

qmidecodestringelem: String len 81 >= Max Len 65

Fix this by matching with servreglocpfrreq's reason field.

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

net: ethernet: mtkppe: avoid NULL deref when gmac0 is disabled

If the gmac0 is disabled, the precheck for a valid ingress device will cause a NULL pointer deref and crash the system. This happens because eth->netdev[0] will be NULL but the code will directly try to access netdevops.

Instead of just checking for the first netdevice, it must be checked if any of the mtketh netdevices is matching the netdevops of the ingress device.

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

mac80211: fix crash in ieee80211chanbwchange for APVLAN stations

ieee80211chanbwchange() iterates all stations and accesses link->reserved.oper via sta->sdata->link[linkid]. For stations on APVLAN interfaces (e.g. 4addr WDS clients), sta->sdata points to the VLAN sdata, whose link never participates in chanctx reservations. This leaves link->reserved.oper zero-initialized with chan == NULL, causing a NULL pointer dereference in ieee80211stacaprxbw() when accessing chandef->chan->band during CSA.

Resolve the VLAN sdata to its parent AP sdata using getbsssdata() before accessing link data.

[also change sta->sdata in ARRAYSIZE even if it doesn't matter]

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

mptcp: pm: in-kernel: always mark signal+subflow endp as used

Syzkaller managed to find a combination of actions that was generating this warning:

msk->pm.localaddrused == 0 WARNING: net/mptcp/pmkernel.c:1071 at marksubflowendpavailable net/mptcp/pmkernel.c:1071 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pmkernel.c:1071 at mptcpnlremovesubflowandsignaladdr net/mptcp/pmkernel.c:1103 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pmkernel.c:1071 at mptcppmnldeladdrdoit+0x81d/0x8f0 net/mptcp/pmkernel.c:1210, CPU#1: syz.2.17/961 Modules linked in: CPU: 1 UID: 0 PID: 961 Comm: syz.2.17 Not tainted 6.19.0-08368-gfafda3b4b06b #22 PREEMPT(full) Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.17.0-debian-1.17.0-1build1 04/01/2014 RIP: 0010:marksubflowendpavailable net/mptcp/pmkernel.c:1071 [inline] RIP: 0010:mptcpnlremovesubflowandsignaladdr net/mptcp/pmkernel.c:1103 [inline] RIP: 0010:mptcppmnldeladdrdoit+0x81d/0x8f0 net/mptcp/pmkernel.c:1210 Code: 89 c5 e8 46 30 6f fe e9 21 fd ff ff 49 83 ed 80 e8 38 30 6f fe 4c 89 ef be 03 00 00 00 e8 db 49 df fe eb ac e8 24 30 6f fe 90 <0f> 0b 90 e9 1d ff ff ff e8 16 30 6f fe eb 05 e8 0f 30 6f fe e8 9a RSP: 0018:ffffc90001663880 EFLAGS: 00010293 RAX: ffffffff82de1a6c RBX: 0000000000000000 RCX: ffff88800722b500 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8880158b22d0 R08: 0000000000010425 R09: ffffffffffffffff R10: ffffffff82de18ba R11: 0000000000000000 R12: ffff88800641a640 R13: ffff8880158b1880 R14: ffff88801ec3c900 R15: ffff88800641a650 FS: 00005555722c3500(0000) GS:ffff8880f909d000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f66346e0f60 CR3: 000000001607c000 CR4: 0000000000350ef0 Call Trace: <TASK> genlfamilyrcvmsgdoit+0x117/0x180 net/netlink/genetlink.c:1115 genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlinkrcvskb+0x16d/0x240 net/netlink/afnetlink.c:2550 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1318 [inline] netlinkunicast+0x3e9/0x4c0 net/netlink/afnetlink.c:1344 netlinksendmsg+0x4aa/0x5b0 net/netlink/afnetlink.c:1894 socksendmsgnosec net/socket.c:727 [inline] socksendmsg+0xc9/0xf0 net/socket.c:742 syssendmsg+0x272/0x3b0 net/socket.c:2592 syssendmsg+0x2de/0x320 net/socket.c:2646 syssendmsg net/socket.c:2678 [inline] dosyssendmsg net/socket.c:2683 [inline] sesyssendmsg net/socket.c:2681 [inline] x64syssendmsg+0x110/0x1a0 net/socket.c:2681 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x143/0x440 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f66346f826d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc83d8bdc8 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6634985fa0 RCX: 00007f66346f826d RDX: 00000000040000b0 RSI: 0000200000000740 RDI: 0000000000000007 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6634985fa8 R13: 00007f6634985fac R14: 0000000000000000 R15: 0000000000001770 </TASK>

The actions that caused that seem to be:

- Set the MPTCP subflows limit to 0 - Create an MPTCP endpoint with both the 'signal' and 'subflow' flags - Create a new MPTCP connection from a different address: an ADDADDR linked to the MPTCP endpoint will be sent ('signal' flag), but no subflows is initiated ('subflow' flag) - Remove the MPTCP endpoint

---truncated---

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

net: ipv4: fix ARM64 alignment fault in multipath hash seed

struct sysctlfibmultipathhashseed contains two u32 fields (userseed and mpseed), making it an 8-byte structure with a 4-byte alignment requirement.

In fibmultipathhashfromkeys(), the code evaluates the entire struct atomically via READONCE():

mpseed = READONCE(net->ipv4.sysctlfibmultipathhashseed).mpseed;

While this silently works on GCC by falling back to unaligned regular loads which the ARM64 kernel tolerates, it causes a fatal kernel panic when compiled with Clang and LTO enabled.

Commit e35123d83ee3 ("arm64: lto: Strengthen READONCE() to acquire when CONFIGLTO=y") strengthens READONCE() to use Load-Acquire instructions (ldar / ldapr) to prevent compiler reordering bugs under Clang LTO. Since the macro evaluates the full 8-byte struct, Clang emits a 64-bit ldar instruction. ARM64 architecture strictly requires ldar to be naturally aligned, thus executing it on a 4-byte aligned address triggers a strict Alignment Fault (FSC = 0x21).

Fix the read side by moving the READONCE() directly to the u32 member, which emits a safe 32-bit ldar Wn.

Furthermore, Eric Dumazet pointed out that WRITEONCE() on the entire struct in procfibmultipathhashsetseed() is also flawed. Analysis shows that Clang splits this 8-byte write into two separate 32-bit str instructions. While this avoids an alignment fault, it destroys atomicity and exposes a tear-write vulnerability. Fix this by explicitly splitting the write into two 32-bit WRITEONCE() operations.

Finally, add the missing READONCE() when reading userseed in procfibmultipathhashseed() to ensure proper pairing and concurrency safety.

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

riscv: trace: fix snapshot deadlock with sbi ecall

If sbiecall.c's functions are traceable,

echo "sbiecall:snapshot" > /sys/kernel/tracing/setftracefilter

may get the kernel into a deadlock.

(Functions in sbiecall.c are excluded from tracing if CONFIGRISCVALTERNATIVEEARLY is set.)

sbiecall triggers a snapshot of the ringbuffer. The snapshot code raises an IPI interrupt, which results in another call to sbiecall and another snapshot...

All it takes to get into this endless loop is one initial sbiecall. On RISC-V systems without SSTC extension, the clock events in timer-riscv.c issue periodic sbi ecalls, making the problem easy to trigger.

Always exclude the sbiecall.c functions from tracing to fix the potential deadlock.

sbi ecalls can easiliy be logged via trace events, excluding ecall functions from function tracing is not a big limitation.

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

x86/vmware: Fix hypercall clobbers

Fedora QA reported the following panic:

BUG: unable to handle page fault for address: 0000000040003e54 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025 RIP: 0010:vmwarehypercall4.constprop.0+0x52/0x90 .. Call Trace: vmmousereportevents+0x13e/0x1b0 psmousehandlebyte+0x15/0x60 ps2interrupt+0x8a/0xd0 ...

because the QEMU VMware mouse emulation is buggy, and clears the top 32 bits of %rdi that the kernel kept a pointer in.

The QEMU vmmouse driver saves and restores the register state in a "uint32t data[6];" and as a result restores the state with the high bits all cleared.

RDI originally contained the value of a valid kernel stack address (0xff5eeb3240003e54). After the vmware hypercall it now contains 0x40003e54, and we get a page fault as a result when it is dereferenced.

The proper fix would be in QEMU, but this works around the issue in the kernel to keep old setups working, when old kernels had not happened to keep any state in %rdi over the hypercall.

In theory this same issue exists for all the hypercalls in the vmmouse driver; in practice it has only been seen with vmwarehypercall3() and vmwarehypercall4(). For now, just mark RDI/RSI as clobbered for those two calls. This should have a minimal effect on code generation overall as it should be rare for the compiler to want to make RDI/RSI live across hypercalls.

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

procfs: avoid fetching build ID while holding VMA lock

Fix PROCMAPQUERY to fetch optional build ID only after dropping mmaplock or per-VMA lock, whichever was used to lock VMA under question, to avoid deadlock reported by syzbot:

-> #1 (&mm->mmaplock){++++}-{4:4}: mightfault+0xed/0x170 copytoiter+0x118/0x1720 copypagetoiter+0x12d/0x1e0 filemapread+0x720/0x10a0 blkdevreaditer+0x2b5/0x4e0 vfsread+0x7f4/0xae0 ksysread+0x12a/0x250 dosyscall64+0xcb/0xf80 entrySYSCALL64afterhwframe+0x77/0x7f

-> #0 (&sb->stype->imutexkey#8){++++}-{4:4}: lockacquire+0x1509/0x26d0 lockacquire+0x185/0x340 downread+0x98/0x490 blkdevreaditer+0x2a7/0x4e0 kernelread+0x39a/0xa90 freaderfetch+0x1d5/0xa80 buildidparse.isra.0+0xea/0x6a0 doprocmapquery+0xd75/0x1050 procfsprocmapioctl+0x7a/0xb0 x64sysioctl+0x18e/0x210 dosyscall64+0xcb/0xf80 entrySYSCALL64afterhwframe+0x77/0x7f

other info that might help us debug this:

Possible unsafe locking scenario:

CPU0 CPU1 ---- ---- rlock(&mm->mmaplock); lock(&sb->stype->imutexkey#8); lock(&mm->mmaplock); rlock(&sb->stype->imutexkey#8);

DEADLOCK

This seems to be exacerbated (as we haven't seen these syzbot reports before that) by the recent:

777a8560fd29 ("lib/buildid: use kernelread() for sleepable context")

To make this safe, we need to grab file refcount while VMA is still locked, but other than that everything is pretty straightforward. Internal buildidparse() API assumes VMA is passed, but it only needs the underlying file reference, so just add another variant buildidparsefile() that expects file passed directly.

[akpm: fix up kerneldoc]

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

net: usb: r8152: fix resume reset deadlock

rtl8152 can trigger device reset during reset which potentially can result in a deadlock:

DPM device timeout after 10 seconds; 15 seconds until panic Call Trace: <TASK> schedule+0x483/0x1370 schedulepreemptdisabled+0x15/0x30 mutexlockcommon+0x1fd/0x470 rtl8152setmacaddress+0x80/0x1f0 devsetmacaddress+0x7f/0x150 rtl8152postreset+0x72/0x150 usbresetdevice+0x1d0/0x220 rtl8152resume+0x99/0xc0 usbresumeinterface+0x3e/0xc0 usbresumeboth+0x104/0x150 usbresume+0x22/0x110

The problem is that rtl8152 resume calls reset under tp->control mutex while reset basically re-enters rtl8152 and attempts to acquire the same tp->control lock once again.

Reset INACCESSIBLE device outside of tp->control mutex scope to avoid recursive mutexlock() deadlock.

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

ice: Fix NULL pointer dereference in icevsisetnapiqueues

Add NULL pointer checks in icevsisetnapiqueues() to prevent crashes during resume from suspend when rings[qidx]->qvector is NULL.

Tested adaptor: 60:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller E810-XXV for SFP [8086:159b] (rev 02) Subsystem: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003]

SR-IOV state: both disabled and enabled can reproduce this issue.

kernel version: v6.18

Reproduce steps: Boot up and execute suspend like systemctl suspend or rtcwake.

Log: <1>[ 231.443607] BUG: kernel NULL pointer dereference, address: 0000000000000040 <1>[ 231.444052] #PF: supervisor read access in kernel mode <1>[ 231.444484] #PF: errorcode(0x0000) - not-present page <6>[ 231.444913] PGD 0 P4D 0 <4>[ 231.445342] Oops: Oops: 0000 [#1] SMP NOPTI <4>[ 231.446635] RIP: 0010:netifqueuesetnapi+0xa/0x170 <4>[ 231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b <48> 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89 <4>[ 231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202 <4>[ 231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010 <4>[ 231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000 <4>[ 231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000 <4>[ 231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 <4>[ 231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000 <4>[ 231.450265] FS: 00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000 <4>[ 231.450715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0 <4>[ 231.451629] PKRU: 55555554 <4>[ 231.452076] Call Trace: <4>[ 231.452549] <TASK> <4>[ 231.452996] ? icevsisetnapiqueues+0x4d/0x110 [ice] <4>[ 231.453482] iceresume+0xfd/0x220 [ice] <4>[ 231.453977] ? pfxpcipmresume+0x10/0x10 <4>[ 231.454425] pcipmresume+0x8c/0x140 <4>[ 231.454872] ? pfxpcipmresume+0x10/0x10 <4>[ 231.455347] dpmruncallback+0x5f/0x160 <4>[ 231.455796] ? dpmwaitforsuperior+0x107/0x170 <4>[ 231.456244] deviceresume+0x177/0x270 <4>[ 231.456708] dpmresume+0x209/0x2f0 <4>[ 231.457151] dpmresumeend+0x15/0x30 <4>[ 231.457596] suspenddevicesandenter+0x1da/0x2b0 <4>[ 231.458054] enterstate+0x10e/0x570

Add defensive checks for both the ring pointer and its qvector before dereferencing, allowing the system to resume successfully even when qvectors are unmapped.

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

block: zero non-PI portion of auto integrity buffer

The auto-generated integrity buffer for writes needs to be fully initialized before being passed to the underlying block device, otherwise the uninitialized memory can be read back by userspace or anyone with physical access to the storage device. If protection information is generated, that portion of the integrity buffer is already initialized. The integrity data is also zeroed if PI generation is disabled via sysfs or the PI tuple size is 0. However, this misses the case where PI is generated and the PI tuple size is nonzero, but the metadata size is larger than the PI tuple. In this case, the remainder ("opaque") of the metadata is left uninitialized. Generalize the BLKINTEGRITYCSUMNONE check to cover any case when the metadata is larger than just the PI tuple.

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

block: Remove queue freezing from several sysfs store callbacks

Freezing the request queue from inside sysfs store callbacks may cause a deadlock in combination with the dm-multipath driver and the queueifnopath option. Additionally, freezing the request queue slows down system boot on systems where sysfs attributes are set synchronously.

Fix this by removing the blkmqfreezequeue() / blkmqunfreezequeue() calls from the store callbacks that do not strictly need these callbacks. Add the dataracy annotation to requestqueue.rqtimeout to suppress KCSAN data race reports about the rqtimeout reads.

This patch may cause a small delay in applying the new settings.

For all the attributes affected by this patch, I/O will complete correctly whether the old or the new value of the attribute is used.

This patch affects the following sysfs attributes: iopolldelay iotimeout nomerges readaheadkb rqaffinity

Here is an example of a deadlock triggered by running test srp/002 if this patch is not applied:

task:multipathd Call Trace: <TASK> schedule+0x8c1/0x1bf0 schedule+0xdd/0x270 schedulepreemptdisabled+0x1c/0x30 mutexlock+0xb89/0x1650 mutexlocknested+0x1f/0x30 dmtablesetrestrictions+0x823/0xdf0 bind+0x166/0x590 dmswaptable+0x2a7/0x490 doresume+0x1b1/0x610 devsuspend+0x55/0x1a0 ctlioctl+0x3a5/0x7e0 dmctlioctl+0x12/0x20 x64sysioctl+0x127/0x1a0 x64syscall+0xe2b/0x17d0 dosyscall64+0x96/0x3a0 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK> task:(udev-worker) Call Trace: <TASK> schedule+0x8c1/0x1bf0 schedule+0xdd/0x270 blkmqfreezequeuewait+0xf2/0x140 blkmqfreezequeuenomemsave+0x23/0x30 queuerastore+0x14e/0x290 queueattrstore+0x23e/0x2c0 sysfskfwrite+0xde/0x140 kernfsfopwriteiter+0x3b2/0x630 vfswrite+0x4fd/0x1390 ksyswrite+0xfd/0x230 x64syswrite+0x76/0xc0 x64syscall+0x276/0x17d0 dosyscall64+0x96/0x3a0 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK>

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

btrfs: fix subvolume deletion lockup caused by inodes xarray race

There is a race condition between inode eviction and inode caching that can cause a live struct btrfsinode to be missing from the root->inodes xarray. Specifically, there is a window during evict() between the inode being unhashed and deleted from the xarray. If btrfsiget() is called for the same inode in that window, it will be recreated and inserted into the xarray, but then eviction will delete the new entry, leaving nothing in the xarray:

Thread 1 Thread 2 --------------------------------------------------------------- evict() removeinodehash() btrfsigetpath() btrfsigetlocked() btrfsreadlockedinode() btrfsaddinodetoroot() destroyinode() btrfsdestroyinode() btrfsdelinodefromroot() xaerase

In turn, this can cause issues for subvolume deletion. Specifically, if an inode is in this lost state, and all other inodes are evicted, then btrfsdelinodefromroot() will call btrfsadddeadroot() prematurely. If the lost inode has a delayednode attached to it, then when btrfscleanonedeletedsnapshot() calls btrfskillalldelayednodes(), it will loop forever because the delayednodes xarray will never become empty (unless memory pressure forces the inode out). We saw this manifest as soft lockups in production.

Fix it by only deleting the xarray entry if it matches the given inode (using xacmpxchg()).

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

fbnic: Move phylink resume out of servicetask and into open/close

The fbnic driver was presenting with the following locking assert coming out of a PM resume: [ 42.208116][ T164] RTNL: assertion failed at drivers/net/phy/phylink.c (2611) [ 42.208492][ T164] WARNING: CPU: 1 PID: 164 at drivers/net/phy/phylink.c:2611 phylinkresume+0x190/0x1e0 [ 42.208872][ T164] Modules linked in: [ 42.209140][ T164] CPU: 1 UID: 0 PID: 164 Comm: bash Not tainted 6.17.0-rc2-virtme #134 PREEMPT(full) [ 42.209496][ T164] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 [ 42.209861][ T164] RIP: 0010:phylinkresume+0x190/0x1e0 [ 42.210057][ T164] Code: 83 e5 01 0f 85 b0 fe ff ff c6 05 1c cd 3e 02 01 90 ba 33 0a 00 00 48 c7 c6 20 3a 1d a5 48 c7 c7 e0 3e 1d a5 e8 21 b8 90 fe 90 <0f> 0b 90 90 e9 86 fe ff ff e8 42 ea 1f ff e9 e2 fe ff ff 48 89 ef [ 42.210708][ T164] RSP: 0018:ffffc90000affbd8 EFLAGS: 00010296 [ 42.210983][ T164] RAX: 0000000000000000 RBX: ffff8880078d8400 RCX: 0000000000000000 [ 42.211235][ T164] RDX: 0000000000000000 RSI: 1ffffffff4f10938 RDI: 0000000000000001 [ 42.211466][ T164] RBP: 0000000000000000 R08: ffffffffa2ae79ea R09: fffffbfff4b3eb84 [ 42.211707][ T164] R10: 0000000000000003 R11: 0000000000000000 R12: ffff888007ad8000 [ 42.211997][ T164] R13: 0000000000000002 R14: ffff888006a18800 R15: ffffffffa34c59e0 [ 42.212234][ T164] FS: 00007f0dc8e39740(0000) GS:ffff88808f51f000(0000) knlGS:0000000000000000 [ 42.212505][ T164] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 42.212704][ T164] CR2: 00007f0dc8e9fe10 CR3: 000000000b56d003 CR4: 0000000000772ef0 [ 42.213227][ T164] PKRU: 55555554 [ 42.213366][ T164] Call Trace: [ 42.213483][ T164] <TASK> [ 42.213565][ T164] fbnicpmattach.isra.0+0x8e/0xa0 [ 42.213725][ T164] pciresetfunction+0x116/0x1d0 [ 42.213895][ T164] resetstore+0xa0/0x100 [ 42.214025][ T164] ? pcidevresetattrisvisible+0x50/0x50 [ 42.214221][ T164] ? sysfsfilekobj+0xc1/0x1e0 [ 42.214374][ T164] ? sysfskfwrite+0x65/0x160 [ 42.214526][ T164] kernfsfopwriteiter+0x2f8/0x4c0 [ 42.214677][ T164] ? kernfsvmapagemkwrite+0x1f0/0x1f0 [ 42.214836][ T164] newsyncwrite+0x308/0x6f0 [ 42.214987][ T164] ? lockacquire+0x34c/0x740 [ 42.215135][ T164] ? newsyncread+0x6f0/0x6f0 [ 42.215288][ T164] ? lockacquire.part.0+0xbc/0x260 [ 42.215440][ T164] ? ksyswrite+0xff/0x200 [ 42.215590][ T164] ? perftraceschedswitch+0x6d0/0x6d0 [ 42.215742][ T164] vfswrite+0x65e/0xbb0 [ 42.215876][ T164] ksyswrite+0xff/0x200 [ 42.215994][ T164] ? ia32sysread+0xc0/0xc0 [ 42.216141][ T164] ? douseraddrfault+0x269/0x9f0 [ 42.216292][ T164] ? rcuiswatching+0x15/0xd0 [ 42.216442][ T164] dosyscall64+0xbb/0x360 [ 42.216591][ T164] entrySYSCALL64afterhwframe+0x4b/0x53 [ 42.216784][ T164] RIP: 0033:0x7f0dc8ea9986

A bit of digging showed that we were invoking the phylinkresume as a part of the fbnicup path when we were enabling the service task while not holding the RTNL lock. We should be enabling this sooner as a part of the ndoopen path and then just letting the service task come online later. This will help to enforce the correct locking and brings the phylink interface online at the same time as the network interface, instead of at a later time.

I tested this on QEMU to verify this was working by putting the system to sleep using "echo mem > /sys/power/state" to put the system to sleep in the guest and then using the command "systemwakeup" in the QEMU monitor.

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

mm/damon/ops-common: ignore migration request to invalid nodes

damonmigratepages() tries migration even if the target node is invalid. If users mistakenly make such invalid requests via DAMOSMIGRATE{HOT,COLD} action, the below kernel BUG can happen.

[ 7831.883495] BUG: unable to handle page fault for address: 0000000000001f48 [ 7831.884160] #PF: supervisor read access in kernel mode [ 7831.884681] #PF: errorcode(0x0000) - not-present page [ 7831.885203] PGD 0 P4D 0 [ 7831.885468] Oops: Oops: 0000 [#1] SMP PTI [ 7831.885852] CPU: 31 UID: 0 PID: 94202 Comm: kdamond.0 Not tainted 6.16.0-rc5-mm-new-damon+ #93 PREEMPT(voluntary) [ 7831.886913] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.el9 04/01/2014 [ 7831.887777] RIP: 0010:allocfrozenpagesnoprof (include/linux/mmzone.h:1724 include/linux/mmzone.h:1750 mm/pagealloc.c:4936 mm/pagealloc.c:5137) [...] [ 7831.895953] Call Trace: [ 7831.896195] <TASK> [ 7831.896397] folioallocnoprof (mm/pagealloc.c:5183 mm/pagealloc.c:5192) [ 7831.896787] migratepagesbatch (mm/migrate.c:1189 mm/migrate.c:1851) [ 7831.897228] ? pfxallocmigrationtarget (mm/migrate.c:2137) [ 7831.897735] migratepages (mm/migrate.c:2078) [ 7831.898141] ? pfxallocmigrationtarget (mm/migrate.c:2137) [ 7831.898664] damonmigratefoliolist (mm/damon/ops-common.c:321 mm/damon/ops-common.c:354) [ 7831.899140] damonmigratepages (mm/damon/ops-common.c:405) [...]

Add a target node validity check in damonmigratepages(). The validity check is stolen from that of dopagesmove(), which is being used for the movepages() system call.

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

HID: apple: validate feature-report field count to prevent NULL pointer dereference

A malicious HID device with quirk APPLEMAGICBACKLIGHT can trigger a NULL pointer dereference whilst the power feature-report is toggled and sent to the device in applemagicbacklightreportset(). The power feature-report is expected to have two data fields, but if the descriptor declares one field then accessing field[1] and dereferencing it in applemagicbacklightreportset() becomes invalid since field[1] will be NULL.

An example of a minimal descriptor which can cause the crash is something like the following where the report with ID 3 (power report) only references a single 1-byte field. When hid core parses the descriptor it will encounter the final feature tag, allocate a hidreport (all members of field[] will be zeroed out), create field structure and populate it, increasing the maxfield to 1. The subsequent field[1] access and dereference causes the crash.

Usage Page (Vendor Defined 0xFF00) Usage (0x0F) Collection (Application) Report ID (1) Usage (0x01) Logical Minimum (0) Logical Maximum (255) Report Size (8) Report Count (1) Feature (Data,Var,Abs)

Usage (0x02) Logical Maximum (32767) Report Size (16) Report Count (1) Feature (Data,Var,Abs)

Report ID (3) Usage (0x03) Logical Minimum (0) Logical Maximum (1) Report Size (8) Report Count (1) Feature (Data,Var,Abs) End Collection

Here we see the KASAN splat when the kernel dereferences the NULL pointer and crashes:

[ 15.164723] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN NOPTI [ 15.165691] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 15.165691] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0 #31 PREEMPT(voluntary) [ 15.165691] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 15.165691] RIP: 0010:applemagicbacklightreportset+0xbf/0x210 [ 15.165691] Call Trace: [ 15.165691] <TASK> [ 15.165691] appleprobe+0x571/0xa20 [ 15.165691] hiddeviceprobe+0x2e2/0x6f0 [ 15.165691] reallyprobe+0x1ca/0x5c0 [ 15.165691] driverprobedevice+0x24f/0x310 [ 15.165691] driverprobedevice+0x4a/0xd0 [ 15.165691] deviceattachdriver+0x169/0x220 [ 15.165691] busforeachdrv+0x118/0x1b0 [ 15.165691] deviceattach+0x1d5/0x380 [ 15.165691] deviceinitialprobe+0x12/0x20 [ 15.165691] busprobedevice+0x13d/0x180 [ 15.165691] deviceadd+0xd87/0x1510 [...]

To fix this issue we should validate the number of fields that the backlight and power reports have and if they do not have the required number of fields then bail.

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

net: ethernet: rtsn: Fix a null pointer dereference in rtsnprobe()

Add check for the return value of rcargen4ptpalloc() to prevent potential null pointer dereference.