bpf: Fix stack-out-of-bounds write in devmap
fs: ntfs3: fix infinite loop triggered by zero-sized ATTRLIST
fs: ntfs3: check return value of indxfind to avoid infinite loop
fs: ntfs3: fix infinite loop in attrloadrunsrange on inconsistent metadata
dmaengine: idxd: fix device leaks on compat bind and unbind
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
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.
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:
topology: Keep the cpumask unchanged when printing cpumap
During fuzz testing, the following warning was discovered:
different return values (15 and 11) from vsnprintf("%pbl ", ...)
test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmapprinttobuf+0x89/0x100 coresiblingslistread+0x7e/0xb0 kernfsfilereaditer+0x15b/0x270 newsyncread+0x153/0x260 vfsread+0x215/0x290 ksysread+0xb9/0x160 dosyscall64+0x56/0x100 entrySYSCALL64afterhwframe+0x78/0xe2
The call trace shows that kvasprintf() reported this warning during the printing of coresiblingslist. kvasprintf() has several steps:
(1) First, calculate the length of the resulting formatted string.
(2) Allocate a buffer based on the returned length.
(3) Then, perform the actual string formatting.
(4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent.
If the corecpumask is modified between steps (1) and (3), the lengths obtained in these two steps may not match. Indeed our test includes cpu hotplugging, which should modify corecpumask while printing.
To fix this issue, cache the cpumask into a temporary variable before calling cpumapprint{list, cpumask}tobuf(), to keep it unchanged during the printing process.
bpf: Cancel the running bpftimer through kworker for PREEMPTRT
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: run set info with opener credentials
SMB2 SETINFO handlers call path-based VFS helpers after checking the access mask granted to the SMB handle. Those helpers perform their owner, inode permission and LSM checks using the current ksmbd worker credentials.
Run the complete SETINFO dispatch with the credentials captured when the handle was opened. This also removes the separate security information credential setup and keeps all SETINFO classes under one credential scope.
Direct overridecreds() is used because it can nest with the request credential overrides already used by rename and link helpers.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: use opener credentials for delete-on-close
Delete-on-close can be completed by deferred or durable handle teardown, where no request work is available. Both the base-file unlink and the ADS xattr removal consequently run with the ksmbd worker credentials and can bypass filesystem permission checks.
Run both operations with the credentials captured in struct file when the handle was opened. This preserves the authenticated user's fsuid, fsgid, supplementary groups and capability restrictions at final close.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: use opener credentials for ADS I/O
Alternate data streams are stored as xattrs. Unlike regular file I/O, their read and write paths therefore call VFS xattr helpers which recheck inode permissions and LSM policy using the current task credentials.
Run ADS I/O with the credentials captured when the SMB handle was opened.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: track the connection owning a byte-range lock
SMB2LOCK adds each granted byte-range lock to both the file lock list and the lock list of the connection which handled the request. The final close and durable handle paths, however, remove the connection list entry while holding fp->conn->llistlock.
With SMB3 multichannel, the connection handling the LOCK request can be different from the connection which opened the file. The entry can therefore be removed under a different spinlock from the one protecting the list it belongs to. A concurrent traversal can then access freed struct ksmbdlock and struct filelock objects.
Record the connection owning each lock's clist entry and hold a reference to it while the entry is linked. Use that connection and its llistlock for unlock, rollback, close, and durable preserve. Durable reconnect assigns the new connection as the owner when publishing the locks again.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate NTLMv2 response before updating session key
ksmbdauthntlmv2() derives the NTLMv2 session key into sess->sesskey before it verifies the NTLMv2 response. ksmbddecodentlmsspauthblob() then continues into KEYXCH even when ksmbdauthntlmv2() failed.
With SMB3 multichannel binding, the failed authentication operates on an existing session and the session setup error path does not expire binding sessions. A client can send a binding session setup with a bad NT proof and KEYXCH and still modify sess->sesskey before STATUSLOGONFAILURE is returned.
Relevant path:
smb2sesssetup() -> conn->binding = true -> ntlmauthenticate() -> sessionuser() -> ksmbddecodentlmsspauthblob() -> ksmbdauthntlmv2() -> calcntlmv2hash() -> hmacmd5usingrawkey(..., sess->sesskey) -> cryptomemneq() returns mismatch -> KEYXCH arc4crypt(..., sess->sesskey, ...) -> outerr without expiring the binding session
Derive the base session key into a local buffer and copy it to sess->sesskey only after the proof matches. Return immediately on authentication failure so KEYXCH is only processed after successful authentication.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add a WRITEDAC/WRITEOWNER check to SMB2 SETINFO SECURITY
commit cc57232cae23 ("ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTLSETSPARSE") added a fp->daccess gate to fsctlsetsparse and noted that "similar handle-level checks exist in other functions but are missing here." The SMB2 SETINFO SECURITY arm is one of the missing ones, and the most security-relevant: smb2setinfosec() calls setinfosec() with no per-handle access check.
setinfosec() (fs/smb/server/smbacl.c) re-permissions the file: it rewrites owner/group/mode via notifychange(), rewrites the POSIX ACL via setposixacl(), and on KSMBDSHAREFLAGACLXATTR shares removes and rewrites the Windows security descriptor via ksmbdvfssetsdxattr(). Every other persistent-mutation arm of the sibling handler smb2setinfofile() checks fp->daccess first (FILEWRITEDATA / FILEDELETE / FILEWRITEEA / FILEWRITEATTRIBUTES); the SECURITY arm — which mutates the access control itself — is the only one with no gate.
A client can therefore open a handle with FILEWRITEATTRIBUTES only (no FILEWRITEDAC / FILEWRITEOWNER) and use SMB2SETINFO with InfoType SMB2OINFOSECURITY to rewrite the file's DACL and owner, granting itself access the handle's daccess never carried. Unlike the FSCTL data arms this is a metadata/xattr operation, so there is no FMODEWRITE VFS backstop — the missing fp->daccess check is the entire gate.
Setting a security descriptor is the WRITEDAC / WRITEOWNER operation, so require at least one of those on the handle before re-permissioning the file. -EACCES is mapped to STATUSACCESSDENIED by smb2setinfo().
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: require source read access for duplicate extents
FSCTLDUPLICATEEXTENTSTOFILE passes the source file directly to vfsclonefilerange() or vfscopyfilerange() without checking the SMB access mask granted to the source handle. A handle opened with attribute access can consequently be used to copy file contents into an attacker-readable destination.
Require FILEREADDATA on the source handle before either VFS operation, matching other ksmbd data-copy paths.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix UAF of struct filelock in SMB2LOCK deferred-lock cancellation
When a blocking byte-range lock request is deferred in the FILELOCKDEFERRED path, ksmbd registers the asynchronous work into the connection's asyncrequests list via setupasyncwork(). The cancel callback smb2removeblockedlock() holds a reference to the flock.
If the lock waiter is subsequently woken up but the work state is no longer KSMBDWORKACTIVE (e.g., due to a concurrent cancellation), the cleanup path calls locksfreelock(flock) without dequeuing the work from the asyncrequests list. Concurrently, smb2cancel() walks the list under conn->requestlock and invokes the cancel callback, which then dereferences the already freed 'flock'. This leads to a slab-use-after-free inside wakeupcommon.
Fix this by restructuring the cleanup logic after the worker returns from ksmbdvfsposixlockwait(). Move listdel(&smblock->llist) and releaseasyncwork(work) to the top of the cleanup block. This guarantees that the async work is completely dequeued and serialized under conn->requestlock before locksfreelock(flock) is called, rendering the flock unreachable for any concurrent smb2cancel().
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: serialize QUERYDIRECTORY requests per file
smb2querydir() stores a pointer to its stack-allocated private data in the ksmbdfile readdirdata. Concurrent QUERYDIRECTORY requests using the same file handle can overwrite this pointer while an iteratedir() callback is still using it, resulting in a stack use-after-free.
Add a per-file mutex and hold it while accessing the shared directory enumeration state. The lock covers scan restart, dot entry state, readdirdata setup and iteration, and response construction. This prevents another request from replacing readdirdata.private before the current request has finished using it and also serializes the shared file position.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add a permission check for FSCTLSETZERODATA
FSCTLSETZERODATA in smb2ioctl() destroys file data via ksmbdvfszerodata() -> vfsfallocate(PUNCHHOLE/ZERORANGE) after checking only the share-level KSMBDTREECONNFLAGWRITABLE, with no per-handle access check. A handle opened with only FILEWRITEATTRIBUTES still yields an FMODEWRITE filp (FILEWRITEATTRIBUTES is part of FILEWRITEDESIREACCESSLE, so smb2createopenflags() opens it OWRONLY), so the vfsfallocate FMODEWRITE check does not stop it; only the missing fp->daccess gate would. Reproduced on mainline 7.1-rc7 with KASAN by an authenticated SMB client: a FILEWRITEATTRIBUTES-only handle zeroed 4096 bytes of file data it had no FILEWRITEDATA right to (6/6; a FILEREADDATA-only handle was correctly denied).
This is the unfixed sibling of commit cc57232cae23 ("ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTLSETSPARSE"). Because SETZERODATA writes data (not an attribute), require FILEWRITEDATA.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add permission checks for FSCTLDUPLICATEEXTENTSTOFILE
The FSCTLDUPLICATEEXTENTSTOFILE arm of smb2ioctl() overwrites the destination file's data via vfsclonefilerange() with neither the share-level KSMBDTREECONNFLAGWRITABLE check nor a per-handle fp->daccess check that the other write-bearing arms carry. A client can overwrite destination data on a read-only share, or from a handle opened with only FILEWRITEATTRIBUTES (which still yields an FMODEWRITE filp). FILEWRITEATTRIBUTES-only destination handle overwrote the file's data via the clone. Add both checks, matching the FSCTLSETSPARSE permission fix; require FILEWRITEDATA since this writes data.
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: validate Dirty Page Table capacity in logreplay copylcns
In the analysis pass of $LogFile journal replay, logreplay() copies LCNs from each action log record into an existing Dirty Page Table (DPT) entry without bounding the destination index. A crafted NTFS image with DPT entry lcnsfollow=1 and an action log record with lcnsfollow=2 produces a kernel slab out-of-bounds write at mount time:
BUG: KASAN: slab-out-of-bounds in logreplay+0x654c/0xdb60 Write of size 8 at addr ffff8880095e1040 by task mount
Two attacker-controlled fields can drive j+i past the allocated pagelcns[] array:
1. dp->lcnsfollow (capacity) can be smaller than lrh->lcnsfollow. 2. lrh->targetvcn may be smaller than dp->vcn, making the u64 subtraction wrap to a huge sizet.
Validate target VCN delta and per-record LCN count against the DPT entry capacity, bail via the existing out: cleanup label with -EINVAL.
This mirrors the bounds-check pattern added in commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot") and commit 0ca0485e4b2e ("fs/ntfs3: validate rec->used in journal-replay file record check").
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ebtables: move to two-stage removal scheme
Like previous patches for xtables, follow same pattern in ebtables. We can't reuse xt helpers: ebttable struct layout is incompatible.
table->ops assignment is now done while still holding the ebt mutex to make sure we never expose partially-filled table struct.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xtables: add and use xtablesunregistertableexit
Previous change added xtablesunregistertablepreexit to detach the table from the packetpath and to unlink it from the active table list. In case of rmmod, userspace that is doing set/getsockopt for this table will not be able to re-instantiate the table: 1. The larval table has been removed already 2. existing instantiated table is no longer on the xt pernet table list.
This adds the second stage helper:
unlink the table from the dying list, free the hook ops (if any) and do the audit notification. It replaces xtunregistertable().
bonding: check xdp prog when set bond mode
futex: Prevent lockup in requeue-PI during signal/ timeout wakeup
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: SCO: Fix UAF on scosocktimeout
conn->sk maybe have been unlinked/freed while waiting for scoconnlock so this checks if the conn->sk is still valid by checking if it part of scosklist.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate SID in parent security descriptor during ACL inheritance
Introduce smbvalidatentsdsid() helper to safely validate Owner SID and Group SID inside the NT Security Descriptor (smbntsd) retrieved from the parent directory.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Fix iommumapsgtable() return value check and avoid WARN
Commit "iommu: return full error code from iommumapsgatomic" changed iommumapsgtable() to return an ssizet and negative values in error cases, rather than a sizet and a zero.
Store the return value in the appropriate type and in case of error, return it rather than WARNing.
Patchwork: https://patchwork.freedesktop.org/patch/719685/
In the Linux kernel, the following vulnerability has been resolved:
power: reset: linkstation-poweroff: fix use-after-free in the linkstationpoweroffinit()
Move ofnodeput(dn) after the ofmatchnode() call, which still needs the node pointer. The node reference is correctly released after use.