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:
net: phonet: do not BUGON() in pnsocketautobind() on failed bind
syzbot reported a kernel BUG triggered from pnsocketsendmsg() via pnsocketautobind():
kernel BUG at net/phonet/socket.c:213! RIP: 0010:pnsocketautobind net/phonet/socket.c:213 [inline] RIP: 0010:pnsocketsendmsg+0x240/0x250 net/phonet/socket.c:421 Call Trace: socksendmsgnosec+0x112/0x150 net/socket.c:797 socksendmsg net/socket.c:812 [inline] syssendto+0x402/0x590 net/socket.c:2280 ...
pnsocketautobind() calls pnsocketbind() with port 0 and, on -EINVAL, assumes the socket was already bound and asserts that the port is non-zero:
err = pnsocketbind(sock, ..., sizeof(struct sockaddrpn)); if (err != -EINVAL) return err; BUGON(!pnport(pnsk(sock->sk)->sobject)); return 0; / socket was already bound /
However pnsocketbind() also returns -EINVAL when sk->skstate is not TCPCLOSE, even when the socket has never been bound and pnport() is still 0. In that case the BUGON() fires and panics the kernel from a user-triggerable path.
Treat the "bind returned -EINVAL but pnport() is still 0" case as a regular error and propagate -EINVAL to the caller instead of crashing. Existing callers already translate a non-zero return from pnsocketautobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here only changes behaviour from panic to a normal errno.
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:
pseries/papr-hvpipe: Fix race with interrupt handler
While executing ->ioctl handler or ->release handler, if an interrupt fires on the same cpu, then we can enter into a deadlock.
This patch fixes both these handlers to take spinlockirq{save|restore} versions of the lock to prevent this deadlock.
In the Linux kernel, the following vulnerability has been resolved:
pseries/papr-hvpipe: Fix null ptr deref in paprhvpipedevcreatehandle()
commit 6d3789d347a7 ("papr-hvpipe: convert paprhvpipedevcreatehandle() to FDPREPARE()"), changed the create handle to FDPREPARE(), but it caused kernel null-ptr-deref because after call to retainandnullptr(srcinfo), srcinfo is re-used for adding it to the global list.
Getting the following kernel panic in paprhvpipedevcreatehandle() when trying to add srcinfo to the list. Kernel attempted to write user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on write at 0x00000000 Faulting instruction address: 0xc0000000001b44a0 Oops: Kernel access of bad area, sig: 11 [#1] ... Call Trace: paprhvpipedevioctl+0x1f4/0x48c (unreliable) sysioctl+0x528/0x1064 systemcallexception+0x128/0x360 systemcallvectoredcommon+0x15c/0x2ec
Now, the error handling with FDPREPARE's file cleanup and free(kfree) auto cleanup is getting too convoluted. This is mainly because we need to ensure only 1 user get the srcID handle. To simplify this, we allocate prepare the srcinfo in the beginning and add it to the global list under a spinlock after checking that no duplicates exist.
This simplify the error handling where if the FDADD fails, we can simply remove the srcinfo from the list and consume any pending msg in hvpipe to be cleared, after srcinfo became visible in the global list.
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:
mailbox: add sanity check for channel array
Fail gracefully if there is no channel array attached to the mailbox controller. Otherwise the later dereference will cause an OOPS which might not be seen because mailbox controllers might instantiate very early. Remove the comment explaining the obvious while here.
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:
i2c: dev: prevent integer overflow in I2CTIMEOUT ioctl
While fuzzing with Syzkaller, a persistent scheduletimeout: wrong timeout value warning was observed, accompanied by SMBus controller state machine corruption.
The I2CTIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INTMAX, but it is subsequently multiplied by 10 before being passed to msecstojiffies().
A malicious user can pass a large value (e.g., 429496729) that passes the arg > INTMAX check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal (int)m < 0 check in msecstojiffies().
The truncated value is then assigned to client->adapter->timeout (a signed 32-bit int), which is reinterpreted as a negative number. When passed to waitforcompletiontimeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the scheduletimeout warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS).
Fix this by bounding the user argument to INTMAX / 10.
[wsa: move the comment as well]
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.