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:

accel/amdxdna: Fix runtime suspend deadlock when there is pending job

The runtime suspend callback drains the running job workqueue before suspending the device. If a job is still executing and calls pmruntimeresumeandget(), it can deadlock with the runtime suspend path.

Fix this by moving pmruntimeresumeandget() from the job execution routine to the job submission routine, ensuring the device is resumed before the job is queued and avoiding the deadlock during runtime suspend.

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

ALSA: ctxfi: Don't enumerate SPDIF1 at DAIO initialization

The recent refactoring of xfi driver changed the assignment of atc->daios[] at atcgetresources(); now it loops over all enum DAIOTYP entries while it looped formerly only a part of them. The problem is that the last entry, SPDIF1, is a special type that is used only for hw20k1 CTSB073X model (as a replacement of SPDIFIO), and there is no corresponding definition for hw20k2. Due to the lack of the info, it caused a kernel crash on hw20k2, which was already worked around by the commit b045ab3dff97 ("ALSA: ctxfi: Fix missing SPDIFI1 index handling").

This patch addresses the root cause of the regression above properly, simply by skipping the incorrect SPDIF1 type in the parser loop.

For making the change clearer, the code is slightly arranged, too.

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

accel/amdxdna: Fix dead lock for suspend and resume

When an application issues a query IOCTL while auto suspend is running, a deadlock can occur. The query path holds devlock and then calls pmruntimeresumeandget(), which waits for the ongoing suspend to complete. Meanwhile, the suspend callback attempts to acquire devlock and blocks, resulting in a deadlock.

Fix this by releasing devlock before calling pmruntimeresumeandget() and reacquiring it after the call completes. Also acquire devlock in the resume callback to keep the locking consistent.

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

accel/amdxdna: Fix race condition when checking rpmon

When autosuspend is triggered, driver rpmon flag is set to indicate that a suspend/resume is already in progress. However, when a userspace application submits a command during this narrow window, amdxdnapmresumeget() may incorrectly skip the resume operation because the rpmon flag is still set. This results in commands being submitted while the device has not actually resumed, causing unexpected behavior.

The setdpm() is called by suspend/resume, it relied on rpmon flag to avoid calling into rpm suspend/resume recursivly. So to fix this, remove the use of the rpmon flag entirely. Instead, introduce aie2pmsetdpm() which explicitly resumes the device before invoking setdpm(). With this change, setdpm() is called directly inside the suspend or resume execution path. Otherwise, aie2pmsetdpm() is called.

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

net: bcmasp: fix txspbringfull() checking same slot cnt times

The loop initialised nextindex from intf->txspbindex on every iteration, so incrring() always produced the same result and only one slot was ever tested. Move the initialisation before the loop so each iteration advances nextindex and the function correctly checks that cnt consecutive descriptor slots are available before allowing a new transmission.

btrfs: do not force reloc root creation during qgroupaccountsnapshot()

btrfs: fix the possible bioclist memory leak during error

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

iouring/io-wq: re-check IOWQBITEXIT for each linked work item

commit 10dc95939817 ("iouring/io-wq: check IOWQBITEXIT inside work run loop") fixed the obvious case where ioworkerhandlework() took one exit-bit snapshot before draining pending work, but the fix stops one level too early.

ioworkerhandlework() now re-checks IOWQBITEXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If iowqexitstart() sets IOWQBITEXIT after the first linked item has started, the remaining linked items can still reuse stale dokill = false, skip IOWQWORKCANCEL, and continue running after exit has begun.

Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.

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

proc: protect ptracemayaccess() with execupdatelock (part 1)

Fix the easy cases where procfs currently calls ptracemayaccess() without execupdatelock protection, where the fix is to simply add the extra lock or use mmaccess():

- dotaskstat(): grab execupdatelock - procpidwchan(): grab execupdatelock - procmapfileslookup(): use mmaccess() instead of gettaskmm() - procmapfilesreaddir(): use mmaccess() instead of gettaskmm() - procnsgetlink(): grab execupdatelock - procnsreadlink(): grab execupdatelock

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

posix-cpu-timers: Fix pid refcount leak in docpunanosleep() error path

In docpunanosleep(), posixcputimercreate() takes a pid reference via getpid() and stores it in timer.it.cpu.pid. If the subsequent posixcputimerset() call fails, the function returns immediately without calling posixcputimerdel() to release the pid reference, causing a leak.

Fix it by calling posixcputimerdel() before the unlock-and-return on the error path, consistent with the other exit paths in the same function.

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.

agp/amd64: Fix broken error propagation in agpamd64probe()

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:

nexthop: fix IPv6 route referencing IPv4 nexthop

syzbot reported a panic [1] [2].

When an IPv6 nexthop is replaced with an IPv4 nexthop, the hasv4 flag of all groups containing this nexthop is not updated. This is because nhgroupv4update is only called when replacing AFINET to AFINET6, but the reverse direction (AFINET6 to AFINET) is missed.

This allows a stale hasv4=false to bypass fib6checknexthop, causing IPv6 routes to be attached to groups that effectively contain only AFINET members. Subsequent route lookups then call nexthopfib6nh() which returns NULL for the AFINET member, leading to a NULL pointer dereference.

Fix by calling nhgroupv4update whenever the family changes, not just AFINET to AFINET6.

Reproducer: # AFINET6 blackhole ip -6 nexthop add id 1 blackhole # group with hasv4=false ip nexthop add id 100 group 1 # replace with AFINET (no -6), hasv4 stays false ip nexthop replace id 1 blackhole # pass stale hasv4 check ip -6 route add 2001:db8::/64 nhid 100 # panic ping -6 2001:db8::1

[1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0 [2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3

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

netfilter: xtables: restrict several matches to inet family

This is a partial revert of:

commit ab4f21e6fb1c ("netfilter: xtables: use NFPROTOUNSPEC in more extensions")

to allow ipv4 and ipv6 only.

- xtmac - xtowner - xtphysdev

These extensions are not used by ebtables in userspace.

Moreover, xtrealm is only for ipv4, since dst->tclassid is ipv4 specific.

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.

afunix: Reject SIOCATMARK on non-stream sockets