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:
netfilter: xtables: allocate hook ops while under mutex
arp/ip(6)tregistertable() add the table to the per-netns list via xtregistertable() before allocating the per-netns hook ops copy via kmemduparray(). This leaves a window where the table is visible in the list with ops=NULL.
If the pernet exit happens runs concurrently the preexit callback finds the table via xtfindtable() and passes the NULL ops pointer to nfunregisternethooks(), causing a NULL dereference:
general protection fault in nfunregisternethooks+0xbc/0x150 RIP: nfunregisternethooks (net/netfilter/core.c:613) Call Trace: iptunregistertablepreexit iptablemanglenetpreexit opspreexitlist cleanupnet
Fix by moving the ops allocation into the xtables core so the table is never in the list without valid ops. Also ensure the table is no longer processing packets before its torn down on error unwind. nfregisternethooks might have published at least one hook; call synchronizercu() if there was an error.
audit log register message gets deferred until all operations have passed, this avoids need to emit another ureg message in case of error unwinding.
Based on earlier patch by Tristan Madani.
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:
drm/amd/display: Wrap DCN32 phantom-plane allocation in DCRUNWITHPREEMPTIONENABLED
[Why] dcn32validatebandwidth() wraps dcn32internalvalidatebw() with DCFPSTART()/DCFPEND(). In x86 non-RT, DCFPSTART takes fpregslock(), which disables local softirqs.
The DML1 path through dcn32enablephantomplane() calls kvzalloc() to allocate ~335 KiB for dcplanestate. This triggers the vmalloc path, which calls BUGON(ininterrupt()) because it's invoked within the FPU-enabled (softirq disabled) region, leading to a kernel crash.
[How] Wrap the dcstatecreatephantomplane() call with the DCRUNWITHPREEMPTIONENABLED() macro to allow preemption during this memory allocation.
(cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)
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:
drm/ttm: Fix ttmboswapout() infinite LRU walk on swapout failure
When ttmttswapout() fails, the current code calls ttmresourceaddbulkmove() followed by ttmresourcemovetolrutail() to restore the resource's bulkmove membership.
However, ttmresourcemovetolrutail() places the resource at the tail of the LRU list which, relative to the walk cursor's hitch node (placed immediately after the resource when it was yielded), puts the resource in front of the the hitch. The next listforeachentrycontinue() from the hitch finds the same resource again, causing an infinite loop.
Fix by deferring delbulkmove to the success path only.
On the success path, TTMTTFLAGSWAPPED has just been set by ttmttswapout() but the resource is still tracked in the bulkmove range, so ttmresourcedelbulkmove()'s !ttmresourceunevictable() guard would incorrectly skip the removal. Introduce ttmresourcedelbulkmoveunevictable() which bypasses that guard.
In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: Fix ttmboshrink() infinite LRU walk on backup failure
Apply the same fix as b2ed01e7ad ("drm/ttm: Fix ttmboswapout() infinite LRU walk on swapout failure") to the ttmboshrink() path.
Move delbulkmove from before the backup to after success only, using ttmresourcedelbulkmoveunevictable() since the resource is now unevictable once fully backed up.
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:
netfilter: nftct: fix missing expect put in obj eval
nftctexpectobjeval() allocates an expectation and may call nfctexpectrelated(), but never drops its local reference.
Add nfctexpectput(exp) before return to balance allocation.
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.
hwmon: (lm90) Stop work before releasing hwmon device
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.