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

erofs: handle overlapped pclusters out of crafted images properly

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

block: don't overwrite bipvcnt in biointegritycopyuser()

biointegrityaddpage() already sets bipvcnt to 1 for the bounce segment. Overwriting it with nrvecs breaks bipvcnt <= bipmaxvcnt on WRITE (bipmaxvcnt is 1), so the gap-merge checks in block/blk.h read past the bipvec[] flex array. On READ the read is in bounds but lands on a saved user bvec instead of the bounce.

The line was added for split propagation, but biointegrityclone() doesn't copy bipvcnt and BIPCLONEFLAGS excludes BIPCOPYUSER.

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

ksmbd: close durable scavenger races against mfplist lookups

ksmbddurablescavenger() has two related races against any walker that iterates fci->mfplist, including ksmbdlookupfdinode() (used by ksmbdvfsrename) and the share-mode checks in fs/smb/server/smbcommon.c.

(1) fp->node list-head reuse. Durable-preserved handles can remain linked on fci->mfplist after session teardown so share-mode checks still see them while the handle is reconnectable. The scavenger collected expired handles by adding fp->node to a local scavengerlist after removing them from the global durable idr. Because fp->node is the same listhead used by mfplist, listadd(&fp->node, &scavengerlist) overwrites the mfplist links and corrupts both lists. CONFIGDEBUGLIST can report this on the share-mode walk path.

(2) Refcount race against mfplist walkers. The scavenger qualifies an expired durable handle with atomicread(&fp->refcount) > 1 and fp->conn under globalft.lock, removes fp from globalft, then drops globalft.lock before unlinking fp from mfplist and freeing it. During that gap fp is still linked on mfplist with fstate == FPINITED. ksmbdlookupfdinode() under mlock read calls ksmbdfpget() (atomicincnotzero on refcount that is still 1) and takes a live reference; the scavenger then unlinks and frees fp while the holder owns a reference, leading to UAF on the holder's subsequent ksmbdfdput() and on any field reads performed by a concurrent share-mode walker that iterates mfplist without taking ksmbdfpget() (smbcheckpermdleases-like paths).

Fix both:

Stop reusing fp->node as a scavenger-private list node. Remove one expired handle from globalft under globalft.lock, take an explicit transient reference, drop the lock, unlink fp->node from mfplist under fci->mlock, then drop both the durable lifetime and transient references with atomicsubandtest(2, &fp->refcount). If the scavenger is the last putter the close runs there; otherwise an in-flight holder that already raced through the mfplist lookup owns the final close via its ksmbdfdput() path. The one-at-a-time disposal can rescan the durable idr when multiple handles expire in the same pass, but durable scavenging is a background expiration path and the final full scan recomputes mintimeout before the next wait.

Clear fp->persistentid inside ksmbdremovedurablefd() right after idrremove(), so a delayed final close from a holder that snatched fp does not re-issue idrremove() on a persistent id that idralloccyclic() in ksmbdopendurablefd() may have already handed out to a brand-new durable handle.

Bypass the per-conn openfilescount decrement in putfdfinal() when fp is detached from any session table (fp->conn cleared by sessionfdcheck() at durable preserve -- paired with the volatileid clear at unpublish, so checking fp->conn alone is sufficient). The walker that owns the final close runs from an unrelated work->conn whose stats.openfilescount never tracked this durable fp; without this guard the holder would underflow that unrelated counter.

The two races are folded into one patch because patch (1) alone cleans up the corrupted list but leaves a deterministic UAF window for mfplist walkers that the transient-reference and persistentid discipline in (2) close; bisecting onto an intermediate state would land on a UAF that pre-patch chaos merely made less reproducible.

Validation: CONFIGDEBUGLIST coverage for the listhead reuse path. KASAN-enabled direct SMB2 durable-handle coverage that exercised ksmbddurablescavenger() and non-NULL ksmbdlookupfdinode() returns while durable handles expired under concurrent rename lookups, with no KASAN, UAF, list-corruption, ODEBUG, or WARNING reports. ---truncated---

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.

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

pwrseq: core: fix use-after-free in pwrseqdebugfsseqnext()

pwrseqdebugfsseqnext() declares 'next' with free(putdevice), which causes putdevice() to be called on the returned pointer when the variable goes out of scope. This results in a use-after-free since the seqfile framework receives a pointer whose reference has already been dropped.

Simply removing free(putdevice) would fix the UAF but would leak the reference acquired by busfindnextdevice(), as stop() only calls upread(&pwrseqsem) and never releases the device reference.

Fix this by making the reference counting consistent across all seqfile callbacks, matching the standard pattern used by PCI and SCSI:

- start(): use getdevice() so it returns a referenced pointer. - next(): explicitly putdevice(curr) to release the previous device's reference (no NULL check needed - the seqfile framework only calls next() while the previous return was non-NULL). - stop(): putdevice(data) to release the last iterated device's reference, with a NULL guard since stop() may be called with NULL when start() returned NULL or next() reached end-of-sequence.

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)

bpf: Fix helper writes to read-only maps

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

wifi: mac80211: don't use rate mask for offchannel TX either

Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for scanning"), ignore incorrect settings to avoid no supported rate warning reported by syzbot.

The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL.

As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well.

[1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024

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

icmp: change the order of rate limits

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

mm: call the securitymmapfile() LSM hook in remapfilepages()

The remapfilepages syscall handler calls dommap() directly, which doesn't contain the LSM security check. And if the process has called personality(READIMPLIESEXEC) before and remapfilepages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux.

So we should check prot by securitymmapfile LSM hook in the remapfilepages syscall handler before dommap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux.

The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1].

The PoC:

$ cat > test.c

int main(void) { sizet pagesz = sysconf(SCPAGESIZE); int mfd = syscall(SYSmemfdcreate, "test", 0); const char buf = mmap(NULL, 4 pagesz, PROTREAD | PROTWRITE, MAPSHARED, mfd, 0); unsigned int old = syscall(SYSpersonality, 0xffffffff); syscall(SYSpersonality, READIMPLIESEXEC | old); syscall(SYSremapfilepages, buf, pagesz, 0, 2, 0); syscall(SYSpersonality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", ORDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); }

$ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)

[PM: subject line tweaks]

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

f2fs: fix to check atomicfile in f2fs ioctl interfaces

fs/inode: Prevent dumpmapping() accessing invalid dentry.dname.name

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