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.
drm/msm/adreno: Fix a reference leak in a6xxgpuinit()
erofs: fix metabuf leak in inode xattr initialization
In the Linux kernel, the following vulnerability has been resolved:
cachefiles: Fix error return when vfsmkdir() fails
When vfsmkdir() fails, the error code is not extracted from the returned error pointer. This causes mkdirerror to be reached with ret=0, which leads to returning ERRPTR(0) (NULL) instead of a proper error pointer.
Fix this by extracting the error code from the error pointer when vfsmkdir() fails.
In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: fix dma mapping leak on data setup error
We're leaking the initial DMA mapping during iteration if we fail to allocate the tracking descriptor for both PRP and SGL. Unmap the iterator directly; we can't use the existing unmap helper because it depends on the tracking descriptor being successfully allocated, so a new one for an in-use iterator is provided.
The mappings were also leaking when the driver detects an invalid biovec when mapping PRPs, so fix that too.
In the Linux kernel, the following vulnerability has been resolved:
ACPI: button: Fix ACPI GPE handler leak during removal
Commit a7e23ec17fee ("ACPI: button: Install notifier for system events as well") changed the ACPI notify handler type for ACPI buttons to ACPIALLNOTIFY, but it forgot to update acpibuttonremove() to reflect that change. This leads to leaking the notify handler past driver removal, which may cause a kernel crash to occur if ACPI notify on the given device is triggered after removing the driver, and causes a subsequent probe of the given device with the same driver to fail.
Address this by updating the acpiremovenotifyhandler() call in acpibuttonremove() as appropriate.
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: enforce HE/EHT cap/oper consistency
Xiang Mei reports that mac80211 could crash if ehtcap is set but ehtoper isn't. Rather than fixing that for the individual user(s), enforce that both HE/EHT have consistent elements.
In the Linux kernel, the following vulnerability has been resolved:
ptp: ocp: fix resource freeing order
Commit a60fc3294a37 ("ptp: rework ptpclockunregister() to disable events") added a call to ptpdisableallevents() which changes the configuration of pins if they support EXTTS events. In ptpocpdetach() pins resources are freed before ptpclockunregister() and it leads to use-after-free during driver removal. Fix it by changing the order of free/unregister calls. To avoid irq handler running on the other core while ptp device unregistering, call synchronizeirq() after HW is configured to stop producing irqs and no irqs are in-flight.
In the Linux kernel, the following vulnerability has been resolved:
signal: clear JOBCTLPENDINGMASK for caller in zapotherthreads()
When a multi-threaded process receives a stop signal (e.g., SIGSTOP), dosignalstop() sets JOBCTLSTOPPENDING and JOBCTLSTOPCONSUME on all threads and sets signal->groupstopcount to the number of threads. If one of the threads concurrently calls execve(), dethread() invokes zapotherthreads() to kill all other threads. zapotherthreads() aborts the pending group stop by resetting signal->groupstopcount to 0 and clears the JOBCTLPENDINGMASK for all other threads. However, it fails to clear the job control flags for the calling thread.
When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTLSTOPPENDING flag, it calls dosignalstop(), which invokes taskparticipategroupstop(). Since JOBCTLSTOPCONSUME is still set, it attempts to decrement the already-zero signal->groupstopcount, triggering a warning:
sig->groupstopcount == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 taskparticipategroupstop+0x215/0x2d0 Call Trace: <TASK> dosignalstop+0x3be/0x5c0 kernel/signal.c:2619 getsignal+0xa8c/0x1330 kernel/signal.c:2884 archdosignalorrestart+0xbc/0x840 arch/x86/kernel/signal.c:337 exittousermodeloop+0x8c/0x4d0 kernel/entry/common.c:98 dosyscall64+0x33e/0xf80 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>
Fix this race condition by clearing the JOBCTLPENDINGMASK for the calling thread in zapotherthreads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zapprocess() and completesignal(), which correctly clear these flags for all threads including the current one.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: wmadsp: Fix NULL dereference when removing firmware controls
In wmadspcontrolremove() check that the priv pointer is not NULL before attempting to cleanup what it points to.
When csdsp creates a control it calls wmadspcontroladdcb() so that wmadsp can create its own private control data. There are two cases where private data is not created:
1. The control is a SYSTEM control, so an ALSA control is not created.
2. The codec driver has registered a controladd() callback that hides the control, so wmadspcontroladd() is not called.
When csdspremove destroys its control list it calls wmadspcontrolremove() for each control. But wmadspcontrolremove() was attempting to cleanup the private data pointed to by csctl->priv without checking the pointer for NULL.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfconntrack: destroy stale expectfn expectations on unregister
NAT helpers such as nfnath323 store a raw pointer to module text in exp->expectfn (e.g. ipnatq931expect). nfcthelperexpectfnunregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text.
When the expected connection arrives, initconntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nfnath323, then connecting to the expected port:
Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 initconntrack.isra.0 (net/netfilter/nfconntrackcore.c:1862) nfconntrackin (net/netfilter/nfconntrackcore.c:2049) ipv4conntracklocal (net/netfilter/nfconntrackproto.c:223) nfhookslow (net/netfilter/core.c:619) iplocalout (net/ipv4/ipoutput.c:120) tcptransmitskb (net/ipv4/tcpoutput.c:1715) tcpconnect (net/ipv4/tcpoutput.c:4374) tcpv4connect (net/ipv4/tcpipv4.c:345) sysconnect (net/socket.c:2167) Modules linked in: nfconntrackh323 [last unloaded: nfnath323]
Reaching the dangling state requires CAPSYSMODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless.
Add nfcthelperexpectfndestroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronizercu() is introduced. With the fix, the same reproducer runs to completion without the Oops.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: synproxy: add mutex to guard hook reference counting
As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other.
Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.
6lowpan: fix off-by-one in multicast context address compression
In the Linux kernel, the following vulnerability has been resolved:
net/802/mrp: fix vector attribute parsing in mrppduparsevecattr
In mrppduparsevecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process.
The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state.
Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing.
Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value.
Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix possible kfreeskb of ERRPTR
After the patch in the "Fixes" tag, the allocation of the "reply" skb can happen either before or after locking the ovsmutex.
However, error cleanups still follow the classical reversed order, assuming "reply" is allocated before locking: it is freed after unlocking.
If "reply" allocation happens after locking the mutex and it fails, "reply" is left with an ERRPTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer.
Fix this by setting the pointer to NULL after having saved its error value.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xtables: avoid leaking percpu counter pointers
The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot.
On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by xtables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace.
Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.
In the Linux kernel, the following vulnerability has been resolved:
vsock/vmci: fix skackbacklog leak on failed handshake
When vmcitransportrecvconnectingserver() returns an error, vmcitransportrecvlisten() calls vsockremovepending() but never calls skacceptqremoved(). This leaves skackbacklog incremented permanently.
Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause skackbacklog to climb toward skmaxackbacklog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover.
The two existing skacceptqremoved() calls in afvsock.c do not cover this path: line 764 checks vsockispending() which returns false after vsockremovepending(), and line 1889 is only reached on successful accept().
Fix by balancing skacceptqadded() with skacceptqremoved() on the error path.
bnxten: Fix NULL pointer dereference
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftfib: fix stale stack leak via the OIFNAME register
For NFTFIBRESULTOIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTNLOCAL and oif-mismatch paths nftfib{4,6}eval() only writes one register via "dest = 0". The remaining three registers are left as whatever was on the stack in nftdochain()'s struct nftregs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace.
The NFTAFIBFPRESENT existence check has the same shape: it is only meaningful for NFTFIBRESULTOIF, yet it was accepted for any result type while the eval stores a single byte via nftregstore8(), leaving the rest of the declared span stale.
Fix both:
- replace the bare "dest = 0" in the eval with nftfibstoreresult(), which strscpypad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and
- restrict NFTAFIBFPRESENT to NFTFIBRESULTOIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.
In the Linux kernel, the following vulnerability has been resolved:
ipc/shm: serialize orphan cleanup with shmnattch updates
shmdestroyorphaned() walks the shm idr under shmids(ns).rwsem, but that does not serialize all fields tested by shmmaydestroy(). In particular, shmnattch is updated while holding shmperm.lock, and attach paths can do that without holding the rwsem.
Do not decide that an orphaned segment is unused before taking the object lock. Move the shmmaydestroy() check under shmperm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.
In the Linux kernel, the following vulnerability has been resolved:
tracing: Avoid NULL return from histfieldname() on truncation
histfieldname() returns "" everywhere except the fully-qualified VARREF/EXPR case, where snprintf() truncation returns NULL early and bypasses the bottom NULL->"" guard. Callers don't expect NULL: strcat(expr, histfieldname(field, 0)) at traceeventshist.c:1758 and the strcmp() in the sort-key match loop at :4804 both deref it.
system and eventname are bounded by MAXEVENTNAMELEN, but the field name on a VARREF is kstrdup'd from a histogram variable name parsed out of the trigger string and has no length cap, so a long enough var name in a fully qualified reference can reach the truncation path.
Keep the length check but leave fieldname as "" on overflow.
In the Linux kernel, the following vulnerability has been resolved:
gpio: aggregator: remove the software node when deactivating the aggregator
The dynamic software node we create for the aggregator platform device when using configfs is leaked when the device is deactivated. Destroy it as the last step in the tear-down path.
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/oa: Fix execqueue leak on width check in stream open
In xeoastreamopenioctl(), when param.execq->width > 1 the function returns -EOPNOTSUPP directly, skipping the existing errexecq cleanup path. The execqueue reference obtained by xeexecqueuelookup() is leaked.
The exec queue holds a reference on the xefile, which is only dropped during queue teardown. The leaked lookup ref is not on the file's execqueue xarray, so file close cannot release it. This keeps both the exec queue and the file private state pinned indefinitely.
Jump to errexecq instead of returning directly so the reference is released.
(cherry picked from commit 339fa0be9e4a5d69fa47e91f4a36574224fb478f)
In the Linux kernel, the following vulnerability has been resolved:
ethtool: module: avoid leaking a netdev ref on module flash errors
moduleflashfwschedule() is missing undo for setting the "inprogress" flag and taking the netdev reference. Delay taking these, the device can't disappear while we are holding rtnllock.
In the Linux kernel, the following vulnerability has been resolved:
ethtool: module: call ethnlopscomplete() on module flash errors
When validate() fails we are skipping over ethnlopscomplete() even tho we already called ethnlopsbegin().
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: fix dst corruption in same register operation
For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value.
Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode:
table testtable ip flags 0 use 1 handle 1 ip testtable testchain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip testtable testchain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip testtable testchain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]
ethtool: rss: fix indirtable and hkey leak on getrxfh failure
In the Linux kernel, the following vulnerability has been resolved:
ethtool: tsinfo: don't pass ERRPTR to genlmsgcancel on prepare failure
The goto err label leads to:
genlmsgcancel(skb, ehdr); return ret;
If ethnltsinfopreparedump() failed, it has not started a genlmsg. There's nothing to cancel, and passing an error pointer to genlmsgcancel() would cause a crash.
In the Linux kernel, the following vulnerability has been resolved:
bridge: Fix sleep in atomic context in sysfs path
Since the start of the git history, brportstore() always acquired the bridge lock. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function was only used by two STP related attributes (cost and priority).
Nowadays, brportstore() processes a lot more attributes and most of them do not need the bridge lock:
Bridge flags: Only require RTNL. Read locklessly by the data path. Annotations can be added in net-next.
FDB port flushing: Only requires the FDB lock.
Multicast attributes: Only require the multicast lock.
Group forward mask: Only requires RTNL. Read locklessly by the data path. Annotations can be added in net-next.
Backup port: Only requires RTNL. Read locklessly by the data path.
This is a problem as the bridge calls devsetpromiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1].
Fix this by reducing the scope of the bridge lock and only take it when processing the two STP related attributes that require it. Remove the now stale comment from brswitchdevsetportflag(). The SWITCHDEVFDEFER flag can be removed in net-next.
[1] BUG: sleeping function called from invalid context at net/core/devaddrlists.c:1262 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 372, name: bash preemptcount: 201, expected: 0 RCU nest depth: 0, expected: 0 5 locks held by bash/372: #0: ffff88810c51c3f0 (sbwriters#7){.+.+}-{0:0}, at: ksyswrite (fs/readwrite.c:740) #1: ffff888115ce9480 (&of->mutex){+.+.}-{4:4}, at: kernfsfopwriteiter (fs/kernfs/file.c:343) #2: ffff88810b9fd330 (kn->active#37){.+.+}-{0:0}, at: kernfsfopwriteiter (fs/kernfs/file.c:80 fs/kernfs/file.c:344) #3: ffffffffa59473a0 (rtnlmutex){+.+.}-{4:4}, at: brportstore (net/bridge/brsysfsif.c:326) #4: ffff8881099d2d58 (&br->lock){+...}-{3:3}, at: brportstore (./include/linux/spinlock.h:348 net/bridge/brsysfsif.c:345) Preemption disabled at: 0x0 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:94 lib/dumpstack.c:120) mightresched.cold (kernel/sched/core.c:9163) netifrxmoderun (net/core/devaddrlists.c:1262) netifrxmodesync (net/core/devaddrlists.c:1428) devsetpromiscuity (net/core/devapi.c:289) brmanagepromisc (net/bridge/brif.c:135 net/bridge/brif.c:172) brportflagschange (net/bridge/brif.c:242 net/bridge/brif.c:747) storelearning (net/bridge/brsysfsif.c:79 net/bridge/brsysfsif.c:235) brportstore (net/bridge/brsysfsif.c:346) kernfsfopwriteiter (fs/kernfs/file.c:352) newsyncwrite (fs/readwrite.c:595) vfswrite (fs/readwrite.c:688) ksyswrite (fs/readwrite.c:740) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121)
In the Linux kernel, the following vulnerability has been resolved:
bridge: Fix sleep in atomic context in netlink path
Since the introduction of the netlink configuration path for bridge ports in commit 25c71c75ac87 ("bridge: bridge port parameters over netlink"), brsetport() was always called with the bridge lock held around it. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function only processed three STP related netlink attributes (cost, priority and state).
Nowadays, brsetport() processes a lot more attributes and most of them do not need the bridge lock:
Bridge flags: Only require RTNL. Read locklessly by the data path. Annotations can be added in net-next.
FDB port flushing: Only requires the FDB lock.
Multicast attributes: Only require the multicast lock.
Group forward mask: Only requires RTNL. Read locklessly by the data path. Annotations can be added in net-next.
Backup port and NHID: Only require RTNL. Read locklessly by the data path.
This is a problem as the bridge calls devsetpromiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1].
Fix this by reducing the scope of the bridge lock and only take it when processing the three STP related attributes that require it. This is consistent with the multicast attributes where each attribute acquires the multicast lock instead of having one critical section for all relevant attributes.
[1] BUG: sleeping function called from invalid context at net/core/devaddrlists.c:1262 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 356, name: bridge preemptcount: 201, expected: 0 RCU nest depth: 0, expected: 0 2 locks held by bridge/356: #0: ffffffff919473a0 (rtnlmutex){+.+.}-{4:4}, at: rtnetlinkrcvmsg (net/core/rtnetlink.c:80 net/core/rtnetlink.c:7002) #1: ffff888115072d58 (&br->lock){+...}-{3:3}, at: brsetlink (./include/linux/spinlock.h:348 net/bridge/brnetlink.c:1117) Preemption disabled at: 0x0 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:94 lib/dumpstack.c:120) mightresched.cold (kernel/sched/core.c:9163) netifrxmoderun (net/core/devaddrlists.c:1262) netifrxmodesync (net/core/devaddrlists.c:1428) devsetpromiscuity (net/core/devapi.c:289) brmanagepromisc (net/bridge/brif.c:135 net/bridge/brif.c:172) brportflagschange (net/bridge/brif.c:242 net/bridge/brif.c:747) brsetport (net/bridge/brnetlink.c:1000) brsetlink (net/bridge/brnetlink.c:1118) rtnlbridgesetlink (net/core/rtnetlink.c:5572) rtnetlinkrcvmsg (net/core/rtnetlink.c:7005) netlinkrcvskb (net/netlink/afnetlink.c:2550) netlinkunicast (net/netlink/afnetlink.c:1318 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/afnetlink.c:1894) socksendmsg (net/socket.c:787 (discriminator 4) net/socket.c:802 (discriminator 4)) syssendmsg (net/socket.c:2698) syssendmsg (net/socket.c:2752) syssendmsg (net/socket.c:2784) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121)