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

ksmbd: Don't log keys in SMB3 signing and encryption key generation

When KSMBDDEBUGAUTH logging is enabled, generatesmb3signingkey() and generatesmb3encryptionkey() log the session, signing, encryption, and decryption key bytes. Remove the logs to avoid exposing credentials.

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

net/ipv6: ioam6: prevent schema length wraparound in trace fill

ioam6filltracedata() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. ioam6filltracedata() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer.

Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.

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

ksmbd: use checkaddoverflow() to prevent u16 DACL size overflow

setposixaclentriesdacl() and setntacldacl() accumulate ACE sizes in u16 variables. When a file has many POSIX ACL entries, the accumulated size can wrap past 65535, causing the pointer arithmetic (char )pndace + size to land within already-written ACEs. Subsequent writes then overwrite earlier entries, and pndacl->size gets a truncated value.

Use checkaddoverflow() at each accumulation point to detect the wrap before it corrupts the buffer, consistent with existing checkmuloverflow() usage elsewhere in smbacl.c.

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

ksmbd: do not expire session on binding failure

When a multichannel session binding request fails (e.g. wrong password), the error path unconditionally sets sess->state = SMB2SESSIONEXPIRED. However, during binding, sess points to the target session looked up via ksmbdsessionlookupslowpath() -- which belongs to another connection's user. This allows a remote attacker to invalidate any active session by simply sending a binding request with a wrong password (DoS).

Fix this by skipping session expiration when the failed request was a binding attempt, since the session does not belong to the current connection. The reference taken by ksmbdsessionlookupslowpath() is still correctly released via ksmbdusersessionput().

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

net: ethernet: xscale: Check for PTP support properly

In ixp4xxgettsinfo() ixp46xptpfind() is called unconditionally despite this feature only existing on ixp46x, leading to the following splat from tcpdump:

root@OpenWrt:~# tcpdump -vv -X -i eth0 (...) Unable to handle kernel NULL pointer dereference at virtual address 00000238 when read (...) Call trace: ptpclockindex from ixp46xptpfind+0x1c/0x38 ixp46xptpfind from ixp4xxgettsinfo+0x4c/0x64 ixp4xxgettsinfo from ethtoolgettsinfo+0x90/0x108 ethtoolgettsinfo from devethtool+0xa00/0x2648 devethtool from devethtool+0x160/0x234 devethtool from devioctl+0x2cc/0x460 devioctl from sockioctl+0x1ec/0x524 sockioctl from sysioctl+0x51c/0xa94 sysioctl from retfastsyscall+0x0/0x44 (...) Segmentation fault

Check for ixp46x in ixp46xptpfind() before trying to set up PTP to avoid this.

To avoid altering the returned error code from ixp4xxhwtstampset() which before this patch was -EOPNOTSUPP, we return -EOPNOTSUPP from ixp4xxhwtstampset() if ixp46xptpfind() fails no matter the error code. The helper function ixp46xptpfind() helper returns -ENODEV.

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

net: macb: fix clk handling on PCI glue driver removal

platformdeviceunregister() may still want to use the registered clks during runtime resume callback.

Note that there is a commit d82d5303c4c5 ("net: macb: fix use after free on rmmod") that addressed the similar problem of clk vs platform device unregistration but just moved the bug to another place.

Save the pointers to clks into local variables for reuse after platform device is unregistered.

BUG: KASAN: use-after-free in clkprepare+0x5a/0x60 Read of size 8 at addr ffff888104f85e00 by task modprobe/597

CPU: 2 PID: 597 Comm: modprobe Not tainted 6.1.164+ #114 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x8d/0xba printreport+0x17f/0x496 kasanreport+0xd9/0x180 clkprepare+0x5a/0x60 macbruntimeresume+0x13d/0x410 [macb] pmgenericruntimeresume+0x97/0xd0 rpmcallback+0xc8/0x4d0 rpmcallback+0xf6/0x230 rpmresume+0xeeb/0x1a70 pmruntimeresume+0xb4/0x170 busremovedevice+0x2e3/0x4b0 devicedel+0x5b3/0xdc0 platformdevicedel+0x4e/0x280 platformdeviceunregister+0x11/0x50 pcideviceremove+0xae/0x210 deviceremove+0xcb/0x180 devicereleasedriverinternal+0x529/0x770 driverdetach+0xd4/0x1a0 busremovedriver+0x135/0x260 driverunregister+0x72/0xb0 pciunregisterdriver+0x26/0x220 dosysdeletemodule+0x32e/0x550 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x6e/0xd8 </TASK>

Allocated by task 519: kasansavestack+0x2c/0x50 kasansettrack+0x21/0x30 kasankmalloc+0x8e/0x90 clkregister+0x458/0x2890 clkhwregister+0x1a/0x60 clkhwregisterfixedrate+0x255/0x410 clkregisterfixedrate+0x3c/0xa0 macbprobe+0x1d8/0x42e [macbpci] localpciprobe+0xd7/0x190 pcideviceprobe+0x252/0x600 reallyprobe+0x255/0x7f0 driverprobedevice+0x1ee/0x330 driverprobedevice+0x4c/0x1f0 driverattach+0x1df/0x4e0 busforeachdev+0x15d/0x1f0 busadddriver+0x486/0x5e0 driverregister+0x23a/0x3d0 dooneinitcall+0xfd/0x4d0 doinitmodule+0x18b/0x5a0 loadmodule+0x5663/0x7950 dosysfinitmodule+0x101/0x180 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x6e/0xd8

Freed by task 597: kasansavestack+0x2c/0x50 kasansettrack+0x21/0x30 kasansavefreeinfo+0x2a/0x50 kasanslabfree+0x106/0x180 kmemcachefree+0xbc/0x320 clkunregister+0x6de/0x8d0 macbremove+0x73/0xc0 [macbpci] pcideviceremove+0xae/0x210 deviceremove+0xcb/0x180 devicereleasedriverinternal+0x529/0x770 driverdetach+0xd4/0x1a0 busremovedriver+0x135/0x260 driverunregister+0x72/0xb0 pciunregisterdriver+0x26/0x220 dosysdeletemodule+0x32e/0x550 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x6e/0xd8

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

wifi: virtwifi: remove SETNETDEVDEV to avoid use-after-free

Currently we execute SETNETDEVDEV(dev, &priv->lowerdev->dev) for the virtwifi net devices. However, unregistering a virtwifi device in netdevruntodo() can happen together with the device referenced by SETNETDEVDEV().

It can result in use-after-free during the ethtool operations performed on a virtwifi device that is currently being unregistered. Such a net device can have the dev.parent field pointing to the freed memory, but ethnlopsbegin() calls pmruntimegetsync(dev->dev.parent).

Let's remove SETNETDEVDEV for virtwifi to avoid bugs like this:

================================================================== BUG: KASAN: slab-use-after-free in pmruntimeresume+0xe2/0xf0 Read of size 2 at addr ffff88810cfc46f8 by task pm/606

Call Trace: <TASK> dumpstacklvl+0x4d/0x70 printreport+0x170/0x4f3 ? pfxrawspinlockirqsave+0x10/0x10 kasanreport+0xda/0x110 ? pmruntimeresume+0xe2/0xf0 ? pmruntimeresume+0xe2/0xf0 pmruntimeresume+0xe2/0xf0 ethnlopsbegin+0x49/0x270 ethnlsetfeatures+0x23c/0xab0 ? pfxethnlsetfeatures+0x10/0x10 ? kvmschedclockread+0x11/0x20 ? localclocknoinstr+0xf/0xf0 ? localclock+0x10/0x30 ? kasansavetrack+0x25/0x60 ? kasankmalloc+0x7f/0x90 ? genlfamilyrcvmsgattrsparse.isra.0+0x150/0x2c0 genlfamilyrcvmsgdoit+0x1e7/0x2c0 ? pfxgenlfamilyrcvmsgdoit+0x10/0x10 ? pfxcredhascapability.isra.0+0x10/0x10 ? stacktracesave+0x8e/0xc0 genlrcvmsg+0x411/0x660 ? pfxgenlrcvmsg+0x10/0x10 ? pfxethnlsetfeatures+0x10/0x10 netlinkrcvskb+0x121/0x380 ? pfxgenlrcvmsg+0x10/0x10 ? pfxnetlinkrcvskb+0x10/0x10 ? pfxdownread+0x10/0x10 genlrcv+0x23/0x30 netlinkunicast+0x60f/0x830 ? pfxnetlinkunicast+0x10/0x10 ? pfxallocskb+0x10/0x10 netlinksendmsg+0x6ea/0xbc0 ? pfxnetlinksendmsg+0x10/0x10 ? futexqueue+0x10b/0x1f0 syssendmsg+0x7a2/0x950 ? copymsghdrfromuser+0x26b/0x430 ? pfxsyssendmsg+0x10/0x10 ? pfxcopymsghdrfromuser+0x10/0x10 syssendmsg+0xf8/0x180 ? pfxsyssendmsg+0x10/0x10 ? pfxfutexwait+0x10/0x10 ? fdget+0x2e4/0x4a0 syssendmsg+0x11f/0x1c0 ? pfxsyssendmsg+0x10/0x10 dosyscall64+0xe2/0x570 ? excpagefault+0x66/0xb0 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

This fix may be combined with another one in the ethtool subsystem: https://lore.kernel.org/all/20260322075917.254874-1-alex.popov@linux.com/T/#u

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

ksmbd: validate numaces and harden ACE walk in smbinheritdacl()

smbinheritdacl() trusts the on-disk numaces value from the parent directory's DACL xattr and uses it to size a heap allocation:

acesbase = kmalloc(sizeof(struct smbace) numaces 2, ...);

numaces is a u16 read from le16tocpu(parentpdacl->numaces) without checking that it is consistent with the declared pdaclsize. An authenticated client whose parent directory's security.NTACL is tampered (e.g. via offline xattr corruption or a concurrent path that bypasses parsedacl()) can present numaces = 65535 with minimal actual ACE data. This causes a ~8 MB allocation (not kzalloc, so uninitialized) that the subsequent loop only partially populates, and may also overflow the three-way sizet multiply on 32-bit kernels.

Additionally, the ACE walk loop uses the weaker offsetof(struct smbace, accessreq) minimum size check rather than the minimum valid on-wire ACE size, and does not reject ACEs whose declared size is below the minimum.

Reproduced on UML + KASAN + LOCKDEP against the real ksmbd code path. A legitimate mount.cifs client creates a parent directory over SMB (ksmbd writes a valid security.NTACL xattr), then the NTACL blob on the backing filesystem is rewritten to set numaces = 0xFFFF while keeping the posixaclhash bytes intact so ksmbdvfsgetsdxattr()'s hash check still passes. A subsequent SMB2 CREATE of a child under that parent drives smb2open() into smbinheritdacl() (share has "vfs objects = aclxattr" set), which fails the page allocator:

WARNING: mm/pagealloc.c:5226 at allocfrozenpagesnoprof+0x46c/0x9c0 Workqueue: ksmbd-io handleksmbdwork allocfrozenpagesnoprof+0x46c/0x9c0 kmalloclargenode+0x68/0x130 kmalloclargenodenoprof+0x24/0x70 kmallocnoprof+0x4c9/0x690 smbinheritdacl+0x394/0x2430 smb2open+0x595d/0xabe0 handleksmbdwork+0x3d3/0x1140

With the patch applied the added guard rejects the tampered value with -EINVAL before any large allocation runs, smb2open() falls back to smb2createsdbuffer(), and the child is created with a default SD. No warning, no splat.

Fix by:

1. Validating numaces against pdaclsize using the same formula applied in parsedacl().

2. Replacing the raw kmalloc(sizeof numaces 2) with kmallocarray(numaces 2, sizeof(...)) for overflow-safe allocation.

3. Tightening the per-ACE loop guard to require the minimum valid ACE size (offsetof(smbace, sid) + CIFSSIDBASESIZE) and rejecting under-sized ACEs, matching the hardening in smbcheckpermdacl() and parsedacl().

v1 -> v2: - Replace the synthetic test-module splat in the changelog with a real-path UML + KASAN reproduction driven through mount.cifs and SMB2 CREATE; Namjae flagged the kcifs3testinheritdaclold name in v1 since it does not exist in ksmbd. - Drop the commit-hash citation from the code comment per Namjae's review; keep the parsedacl() pointer.

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

ksmbd: require minimum ACE size in smbcheckpermdacl()

Both ACE-walk loops in smbcheckpermdacl() only guard against an under-sized remaining buffer, not against an ACE whose declared ace->size is smaller than the struct it claims to describe:

if (offsetof(struct smbace, accessreq) > acessize) break; acesize = le16tocpu(ace->size); if (acesize > acessize) break;

The first check only requires the 4-byte ACE header to be in bounds; it does not require accessreq (4 bytes at offset 4) to be readable. An attacker who has set a crafted DACL on a file they own can declare ace->size == 4 with acessize == 4, pass both checks, and then

granted |= le32tocpu(ace->accessreq); / upper loop / comparesids(&sid, &ace->sid); / lower loop /

reads accessreq at offset 4 (OOB by up to 4 bytes) and ace->sid at offset 8 (OOB by up to CIFSSIDBASESIZE + SIDMAXSUBAUTHORITIES 4 bytes).

Tighten both loops to require

acesize >= offsetof(struct smbace, sid) + CIFSSIDBASESIZE

which is the smallest valid on-wire ACE layout (4-byte header + 4-byte accessreq + 8-byte sid base with zero sub-auths). Also reject ACEs whose sid.numsubauth exceeds SIDMAXSUBAUTHORITIES before letting comparesids() dereference subauth[] entries.

parsesecdesc() already enforces an equivalent check (lines 441-448); smbcheckpermdacl() simply grew weaker validation over time.

Reachability: authenticated SMB client with permission to set an ACL on a file. On a subsequent CREATE against that file, the kernel walks the stored DACL via smbcheckpermdacl() and triggers the OOB read. Not pre-auth, and the OOB read is not reflected to the attacker, but KASAN reports and kernel state corruption are possible.

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

ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc

The kernel ASN.1 BER decoder calls action callbacks incrementally as it walks the input. When ksmbddecodenegTokenInit() reaches the mechToken [2] OCTET STRING element, ksmbdnegtokenalloc() allocates conn->mechToken immediately via kmemdupnul(). If a later element in the same blob is malformed, then the decoder will return nonzero after the allocation is already live. This could happen if mechListMIC [3] overrunse the enclosing SEQUENCE.

decodenegotiationtoken() then sets conn->usespnego = false because both the negTokenInit and negTokenTarg grammars failed. The cleanup at the bottom of smb2sesssetup() is gated on usespnego:

if (conn->usespnego && conn->mechToken) { kfree(conn->mechToken); conn->mechToken = NULL; }

so the kfree is skipped, causing the mechToken to never be freed.

This codepath is reachable pre-authentication, so untrusted clients can cause slow memory leaks on a server without even being properly authenticated.

Fix this up by not checking check for usespnego, as it's not required, so the memory will always be properly freed. At the same time, always free the memory in ksmbdconnfree() incase some other failure path forgot to free it.

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

ksmbd: validate EaNameLength in smb2getea()

smb2getea() reads eareq->EaNameLength from the client request and passes it directly to strncmp() as the comparison length without verifying that the length of the name really is the size of the input buffer received.

Fix this up by properly checking the size of the name based on the value received and the overall size of the request, to prevent a later strncmp() call to use the length as a "trusted" size of the buffer. Without this check, uninitialized heap values might be slowly leaked to the client.

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

smb: server: fix use-after-free in smb2open()

The opinfo pointer obtained via rcudereference(fp->fopinfo) is dereferenced after rcureadunlock(), creating a use-after-free window.

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

smb: server: let senddone handle a completion without IBSENDSIGNALED

With smbdirectsendbatch processing we likely have requests without IBSENDSIGNALED, which will be destroyed in the final request that has IBSENDSIGNALED set.

If the connection is broken all requests are signaled even without explicit IBSENDSIGNALED.

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

smb: server: make use of smbdirectsocket.sendio.bcredits

It turns out that our code will corrupt the stream of reassabled data transfer messages when we trigger an immendiate (empty) send.

In order to fix this we'll have a single 'batch' credit per connection. And code getting that credit is free to use as much messages until remaininglength reaches 0, then the batch credit it given back and the next logical send can happen.

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

ksmbd: fix memory leaks and NULL deref in smb2lock()

smb2lock() has three error handling issues after listdel() detaches smblock from locklist at nocheckcl:

1) If vfslockfile() returns an unexpected error in the non-UNLOCK path, goto out leaks smblock and its flock because the out: handler only iterates locklist and rollbacklist, neither of which contains the detached smblock.

2) If vfslockfile() returns -ENOENT in the UNLOCK path, goto out leaks smblock and flock for the same reason. The error code returned to the dispatcher is also stale.

3) In the rollback path, smbflockinit() can return NULL on allocation failure. The result is dereferenced unconditionally, causing a kernel NULL pointer dereference. Add a NULL check to prevent the crash and clean up the bookkeeping; the VFS lock itself cannot be rolled back without the allocation and will be released at file or connection teardown.

Fix cases 1 and 2 by hoisting the locksfreelock()/kfree() to before the if(!rc) check in the UNLOCK branch so all exit paths share one free site, and by freeing smblock and flock before goto out in the non-UNLOCK branch. Propagate the correct error code in both cases. Fix case 3 by wrapping the VFS unlock in an if(rlock) guard and adding a NULL check for locksfreelock(rlock) in the shared cleanup.

Found via call-graph analysis using sqry.

dmaengine: idxd: fix device leaks on compat bind and unbind

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

net: hns3: fix oops when unload drivers paralleling

When unload hclge driver, it tries to disable sriov first for each aedev node from hnae3aedevlist. If user unloads hns3 driver at the time, because it removes all the aedev nodes, and it may cause oops.

But we can't simply use hnae3commonlock for this. Because in the process flow of pcidisablesriov(), it will trigger the remove flow of VF, which will also take hnae3commonlock.

To fixes it, introduce a new mutex to protect the unload process.

fs: ntfs3: fix infinite loop triggered by zero-sized ATTRLIST

fs: ntfs3: fix infinite loop in attrloadrunsrange on inconsistent metadata

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

drm/v3d: Stop active perfmon if it is being destroyed

If the active performance monitor (v3d->activeperfmon) is being destroyed, stop it first. Currently, the active perfmon is not stopped during destruction, leaving the v3d->activeperfmon pointer stale. This can lead to undefined behavior and instability.

This patch ensures that the active perfmon is stopped before being destroyed, aligning with the behavior introduced in commit 7d1fd3638ee3 ("drm/v3d: Stop the active perfmon before being destroyed").

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

net: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF.

SIOCBRDELIF is passed to devioctl() first and later forwarded to brioctlcall(), which causes unnecessary RTNL dance and the splat below [0] under RTNL pressure.

Let's say Thread A is trying to detach a device from a bridge and Thread B is trying to remove the bridge.

In devioctl(), Thread A bumps the bridge device's refcnt by netdevhold() and releases RTNL because the following brioctlcall() also re-acquires RTNL.

In the race window, Thread B could acquire RTNL and try to remove the bridge device. Then, rtnlunlock() by Thread B will release RTNL and wait for netdevput() by Thread A.

Thread A, however, must hold RTNL after the unlock in devifsioc(), which may take long under RTNL pressure, resulting in the splat by Thread B.

Thread A (SIOCBRDELIF) Thread B (SIOCBRDELBR) ---------------------- ---------------------- sockioctl sockioctl - sockdoioctl - brioctlcall - devioctl - brioctlstub |- rtnllock | |- devifsioc ' ' |- dev = devgetbyname(...) |- netdevhold(dev, ...) . / |- rtnlunlock ------. | | |- brioctlcall ---> |- rtnllock Race | | - brioctlstub |- brdelbridge Window | | | |- dev = devgetbyname(...) | | | May take long | - brdevdelete(dev, ...) | | | under RTNL pressure | - unregisternetdevicequeue(dev, ...) | | | | - rtnlunlock \ | |- rtnllock <-' - netdevruntodo | |- ... - netdevruntodo | - rtnlunlock |- rtnlunlock | |- netdevwaitallrefsany |- netdevput(dev, ...) <----------------' Wait refcnt decrement and log splat below

To avoid blocking SIOCBRDELBR unnecessarily, let's not call devioctl() for SIOCBRADDIF and SIOCBRDELIF.

In the devioctl() path, we do the following:

1. Copy struct ifreq by getuserifreq in sockdoioctl() 2. Check CAPNETADMIN in devioctl() 3. Call devload() in devioctl() 4. Fetch the master dev from ifr.ifrname in devifsioc()

3. can be done by requestmodule() in brioctlcall(), so we move 1., 2., and 4. to brioctlstub().

Note that 2. is also checked later in adddelif(), but it's better performed before RTNL.

SIOCBRADDIF and SIOCBRDELIF have been processed in devioctl() since the pre-git era, and there seems to be no specific reason to process them there.

[0]: unregisternetdevice: waiting for wpan3 to become free. Usage count = 2 reftracker: wpan3@ffff8880662d8608 has 1/1 users at netdevtrackeralloc include/linux/netdevice.h:4282 [inline] netdevhold include/linux/netdevice.h:4311 [inline] devifsioc+0xc6a/0x1160 net/core/devioctl.c:624 devioctl+0x255/0x10c0 net/core/devioctl.c:826 sockdoioctl+0x1ca/0x260 net/socket.c:1213 sockioctl+0x23a/0x6c0 net/socket.c:1318 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:906 [inline] sesysioctl fs/ioctl.c:892 [inline] x64sysioctl+0x1a4/0x210 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcb/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

fs: ntfs3: check return value of indxfind to avoid infinite loop

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

ksmbd: require 3 sub-authorities before reading subauth[2]

parsedacl() compares each ACE SID against sidunixNFSmode and on match reads sid.subauth[2] as the file mode. If sidunixNFSmode is the prefix S-1-5-88-3 with numsubauth = 2 then comparesids() compares only min(numsubauth, 2) sub-authorities so a client SID with numsubauth = 2 and subauth = {88, 3} will match.

If numsubauth = 2 and the ACE is placed at the very end of the security descriptor, subauth[2] will be 4 bytes past endofacl. The out-of-band bytes will then be masked to the low 9 bits and applied as the file's POSIX mode, probably not something that is good to have happen.

Fix this up by forcing the SID to actually carry a third sub-authority before reading it at all.

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

bpf: sockmap: Fix use-after-free of sk->sksocket in skpsockverdictdataready().

syzbot reported use-after-free of AFUNIX socket's sk->sksocket in skpsockverdictdataready(). [0]

In unixstreamsendmsg(), the peer socket's ->skdataready() is called after dropping its unixstatelock().

Although the sender socket holds the peer's refcount, it does not prevent the peer's sockorphan(), and the peer's sksocket might be freed after one RCU grace period.

Let's fetch the peer's sk->sksocket and sk->sksocket->ops under RCU in skpsockverdictdataready().

[0]: BUG: KASAN: slab-use-after-free in skpsockverdictdataready+0xec/0x590 net/core/skmsg.c:1278 Read of size 8 at addr ffff8880594da860 by task syz.4.1842/11013

CPU: 1 UID: 0 PID: 11013 Comm: syz.4.1842 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 Call Trace: <TASK> dumpstacklvl+0xe8/0x150 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xba/0x230 mm/kasan/report.c:482 kasanreport+0x117/0x150 mm/kasan/report.c:595 skpsockverdictdataready+0xec/0x590 net/core/skmsg.c:1278 unixstreamsendmsg+0x8a3/0xe80 net/unix/afunix.c:2482 socksendmsgnosec net/socket.c:721 [inline] socksendmsg net/socket.c:736 [inline] syssendmsg+0x972/0x9f0 net/socket.c:2585 syssendmsg+0x2a5/0x360 net/socket.c:2639 syssendmsg net/socket.c:2671 [inline] dosyssendmsg net/socket.c:2676 [inline] sesyssendmsg net/socket.c:2674 [inline] x64syssendmsg+0x1bd/0x2a0 net/socket.c:2674 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x14d/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7facf899c819 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007facf9827028 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007facf8c15fa0 RCX: 00007facf899c819 RDX: 0000000000000000 RSI: 0000200000000500 RDI: 0000000000000004 RBP: 00007facf8a32c91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007facf8c16038 R14: 00007facf8c15fa0 R15: 00007ffd41b01c78 </TASK>

Allocated by task 11013: kasansavestack mm/kasan/common.c:57 [inline] kasansavetrack+0x3e/0x80 mm/kasan/common.c:78 unpoisonslabobject mm/kasan/common.c:340 [inline] kasanslaballoc+0x6c/0x80 mm/kasan/common.c:366 kasanslaballoc include/linux/kasan.h:253 [inline] slabpostallochook mm/slub.c:4538 [inline] slaballocnode mm/slub.c:4866 [inline] kmemcachealloclrunoprof+0x2b8/0x640 mm/slub.c:4885 sockallocinode+0x28/0xc0 net/socket.c:316 allocinode+0x6a/0x1b0 fs/inode.c:347 newinodepseudo include/linux/fs.h:3003 [inline] sockalloc net/socket.c:631 [inline] sockcreate+0x12d/0x9d0 net/socket.c:1562 sockcreate net/socket.c:1656 [inline] syssocketpair+0x1c4/0x560 net/socket.c:1803 dosyssocketpair net/socket.c:1856 [inline] sesyssocketpair net/socket.c:1853 [inline] x64syssocketpair+0x9b/0xb0 net/socket.c:1853 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x14d/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 15: kasansavestack mm/kasan/common.c:57 [inline] kasansavetrack+0x3e/0x80 mm/kasan/common.c:78 kasansavefreeinfo+0x46/0x50 mm/kasan/generic.c:584 poisonslabobject mm/kasan/common.c:253 [inline] kasanslabfree+0x5c/0x80 mm/kasan/common.c:285 kasanslabfree include/linux/kasan.h:235 [inline] slabfreehook mm/slub.c:2685 [inline] slabfree mm/slub.c:6165 [inline] kmemcachefree+0x187/0x630 mm/slub.c:6295 rcudobatch kernel/rcu/tree.c: ---truncated---

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

fs/ntfs3: validate rec->used in journal-replay file record check

checkfilerecord() validates rec->total against the record size but never validates rec->used. The doaction() journal-replay handlers read rec->used from disk and use it to compute memmove lengths:

DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) changeattrsize: memmove(..., used - PtrOffset(rec, next))

When rec->used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall.

This requires a corrupted filesystem, which isn't a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay

Fix this up by bounding rec->used correctly.

This is much like commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot") which checked different values in this same switch statement.

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

ksmbd: validate response sizes in ipcvalidatemsg()

ipcvalidatemsg() computes the expected message size for each response type by adding (or multiplying) attacker-controlled fields from the daemon response to a fixed struct size in unsigned int arithmetic. Three cases can overflow:

KSMBDEVENTRPCREQUEST: msgsz = sizeof(struct ksmbdrpccommand) + resp->payloadsz; KSMBDEVENTSHARECONFIGREQUEST: msgsz = sizeof(struct ksmbdshareconfigresponse) + resp->payloadsz; KSMBDEVENTLOGINREQUESTEXT: msgsz = sizeof(struct ksmbdloginresponseext) + resp->ngroups sizeof(gidt);

resp->payloadsz is u32 and resp->ngroups is s32. Each addition can wrap in unsigned int; the multiplication by sizeof(gidt) mixes signed and sizet, so a negative ngroups is converted to SIZEMAX before the multiply. A wrapped value of msgsz that happens to equal entry->msgsz bypasses the size check on the next line, and downstream consumers (smb2pdu.c:6742 memcpy using rpcresp->payloadsz, kmemdup in ksmbdallocuser using respext->ngroups) then trust the unverified length.

Use checkaddoverflow() on the RPCREQUEST and SHARECONFIGREQUEST paths to detect integer overflow without constraining functional payload size; userspace ksmbd-tools grows NDR responses in 4096-byte chunks for calls like NetShareEnumAll, so a hard transport cap is unworkable on the response side. For LOGINREQUESTEXT, reject resp->ngroups outside the signed [0, NGROUPSMAX] range up front and report the error from ipcvalidatemsg() so it fires at the IPC boundary; with that bound the subsequent multiplication and addition stay well below UINTMAX. The now-redundant ngroups check and prerr in ksmbdallocuser() are removed.

This is the response-side analogue of aab98e2dbd64 ("ksmbd: fix integer overflows on 32 bit systems"), which hardened the request side.

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

drm/vc4: platformgetirqbyname() returns an int

platformgetirqbyname() will return a negative value if an error happens, so it should be checked and not just passed directly into devmrequestthreadedirq() hoping all will be ok.

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

ext4: always drain queued discard work in ext4mbrelease()

While reviewing recent ext4 patch[1], Sashiko raised the following concern[2]:

If the filesystem is initially mounted with the discard option, deleting files will populate sbi->sdiscardlist and queue sdiscardwork. If it is then remounted with nodiscard, the EXT4MOUNTDISCARD flag is cleared, but the pending sdiscardwork is neither cancelled nor flushed.

[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev

The concern was valid, but it had nothing to do with the patch[1]. One of the problems with Sashiko in its current (early) form is that it will detect pre-existing issues and report it as a problem with the patch that it is reviewing.

In practice, it would be hard to hit deliberately (unless you are a malicious syzkaller fuzzer), since it would involve mounting the file system with -o discard, and then deleting a large number of files, remounting the file system with -o nodiscard, and then immediately unmounting the file system before the queued discard work has a change to drain on its own.

Fix it because it's a real bug, and to avoid Sashiko from raising this concern when analyzing future patches to mballoc.c.

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

ipv6: ioam: fix potential NULL dereferences in ioam6filltracedata()

We need to check in6devget() for possible NULL value, as suggested by Yiming Qian.

Also add skbdstdevrcu() instead of skbdstdev(), and two missing READONCE().

Note that @dev can't be NULL.

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

ksmbd: fix signededness bug in smbdirectpreparenegotiation()

smbdirectpreparenegotiation() casts an unsigned u32 value from sp->maxrecvsize and req->preferredsendsize to a signed int before computing mint(int, ...). A maliciously provided preferredsendsize of 0x80000000 will return as smaller than maxrecvsize, and then be used to set the maximum allowed alowed receive size for the next message.

By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow.

This fix replaces mint(int, ...) with mint(u32)