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:

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:

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.

drm/amd/display: Handle null 'streamstatus' in 'planeschangedforexistingstream'

drm/amd/display: Add NULL check for clkmgr and clkmgr->funcs in dcn30inithw

drm/amd/display: Add NULL check for clkmgr in dcn32inithw

drm/amd/display: Pass non-null to dcn20validateapplypipesplitflags

drm/amd/display: Check linkres->hpodplinkenc before using it

drm/amd/display: Add NULL check for function pointer in dcn32setoutputtransferfunc

drm/amd/display: Add NULL check for function pointer in dcn20setoutputtransferfunc

drm/amd/display: Check null-initialized variables

drm/amd/display: Add null check for 'afb' in amdgpudmplanehandlecursorupdate (v2)

erofs: handle overlapped pclusters out of crafted images properly

drm/amd/display: Skip Recompute DSC Params if no Stream on Link

bpf: Zero former ARGPTRTO{LONGINT} args in case of error

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

rcu-tasks: Fix access non-existent percpu rtpcp variable in rcutasksneedgpcb()

For kernels built with CONFIGFORCENRCPUS=y, the nrcpuids is defined as NRCPUS instead of the number of possible cpus, this will cause the following system panic:

smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setuppercpu: NRCPUS:512 nrcpumaskbits:512 nrcpuids:512 nrnodeids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcutaskstrace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcutasksneedgpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: <TASK> ? die+0x23/0x80 ? pagefaultoops+0xa4/0x180 ? excpagefault+0x152/0x180 ? asmexcpagefault+0x26/0x40 ? rcutasksneedgpcb+0x25d/0x2c0 ? pfxrcutaskskthread+0x40/0x40 rcutasksonegp+0x69/0x180 rcutaskskthread+0x94/0xc0 kthread+0xe8/0x140 ? pfxkthread+0x40/0x40 retfromfork+0x34/0x80 ? pfxkthread+0x40/0x40 retfromforkasm+0x1b/0x80 </TASK>

Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nrcpuids, for configuring enqueue and dequeue limits.

[ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]

drm/amd/display: Check phantomstream before it is used

bpftool: Fix undefined behavior in qsort(NULL 0 ...)

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:

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:

iouring: check if we need to reschedule during overflow flush

In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while.

Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.

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

ext4: fix access to uninitialised lock in fc replay path

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

net: dsa: improve shutdown sequence

Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there.

The first problem is that lan9303 is unique among DSA drivers in that it calls devgetdrvdata() at "arbitrary runtime" (not probe, not shutdown, not remove):

phystatemachine() -> ... -> dsauserphyread() -> ds->ops->phyread() -> lan9303phyread() -> chip->ops->phyread() -> lan9303mdiophyread() -> devgetdrvdata()

But we never stop the phystatemachine(), so it may continue to run after dsaswitchshutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD.

The second problem is that the way in which we set dp->conduit->dsaptr = NULL; is concurrent with receive packet processing. dsaswitchrcv() checks once whether dev->dsaptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsaptr is dereferenced again and again without NULL checks: dsaconduitfinduser() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid.

Both problems have the common aspect that closing the conduit interface solves them.

In the first case, devclose(conduit) triggers the NETDEVGOINGDOWN event in dsausernetdeviceevent() which closes user ports as well. dsaportdisablert() calls phylinkstop(), which synchronously stops the phylink state machine, and ds->ops->phyread() will thus no longer call into the driver after this point.

In the second case, devclose(conduit) should do this, as per Documentation/networking/driver.rst:

| Quiescence | ---------- | | After the ndostop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands.

So it should be sufficient to ensure that later, when we zeroize conduit->dsaptr, there will be no concurrent dsaswitchrcv() call on this conduit.

The addition of the netifdevicedetach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them.

The race condition actually did not exist when commit 0650bf52b31f ("net: dsa: be compatible with masters which unregister on shutdown") first introduced dsaswitchshutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsaptr (one which doesn't ensure that the interfaces aren't up).

block: fix integer overflow in BLKSECDISCARD

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:

wifi: mt76: mt7925: fix NULL deref check in mt7925changeviflinks

In mt7925changeviflinks() devmkzalloc() may return NULL but this returned value is not checked.

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:

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:

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.