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:

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

cpufreq: Fix hotplug-suspend race during reboot

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:

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.

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: 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: 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:

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:

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: 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.

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

net: rtnetlink: zero iflavfbroadcast to avoid stack infoleak in rtnlfillvfinfo

rtnlfillvfinfo() declares struct iflavfbroadcast on the stack without initialisation:

struct iflavfbroadcast vfbroadcast;

The struct contains a single fixed 32-byte field:

/ include/uapi/linux/iflink.h / struct iflavfbroadcast { u8 broadcast[32]; };

The function then copies dev->broadcast into it using dev->addrlen as the length:

memcpy(vfbroadcast.broadcast, dev->broadcast, dev->addrlen);

On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addrlen is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via:

nlaput(skb, IFLAVFBROADCAST, sizeof(vfbroadcast), &vfbroadcast)

leaking up to 26 bytes of uninitialised kernel stack per VF per RTMGETLINK request, repeatable.

The other vf structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vfvlaninfo, nodeguid and portguid a few lines above. vfbroadcast was simply missed when it was added.

Reachability: any unprivileged local process can open AFNETLINK / NETLINKROUTE without capabilities and send RTMGETLINK with an IFLAEXTMASK attribute carrying RTEXTFILTERVF. The kernel walks each VF and emits IFLAVFBROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nlaput() when reproduced.

Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf structs in the same function.

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

ipv6: xfrm6: release dst on error in xfrm6rcvencap()

xfrm6rcvencap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6routeinputlookup() returns a referenced dst entry even when the lookup resolves to an error route.

If dst->error is set, xfrm6rcvencap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries.

Release the dst before jumping to the drop path.

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

inotify: fix watch count leak when fsnotifyaddinodemarklocked() fails

When fsnotifyaddinodemarklocked() fails in inotifynewwatch(), the error path calls inotifyremovefromidr() but does not call decinotifywatches() to undo the preceding incinotifywatches(). This leaks a watch count, and repeated failures can exhaust the maxuserwatches limit with -ENOSPC even when no watches are active.

Prior to commit 1cce1eea0aff ("inotify: Convert to using per-namespace limits"), the watch count was incremented after fsnotifyaddmarklocked() succeeded, so this path was not affected. The conversion moved incinotifywatches() before the mark insertion without adding the corresponding rollback.

Add the missing decinotifywatches() call in the error path.

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

netfilter: reject zero shift in nftbitwise

Reject zero shift operands for nftbitwise left and right shift expressions during initialization.

The carry propagation logic computes the carry from the adjacent 32-bit word using BITSPERTYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour.

Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path.

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

netfilter: nfnetlinkosf: fix divide-by-zero in OSFWSSMODULO

nfosfmatchone() computes ctx->window % f->wss.val in the OSFWSSMODULO branch with no guard for f->wss.val == 0. A CAPNETADMIN user can add such a fingerprint via nfnetlink; a subsequent matching TCP SYN divides by zero and panics the kernel.

Reject the bogus fingerprint in nfnlosfaddcallback() above the per-option for-loop. f->wss is per-fingerprint, not per-option, so the check must run regardless of f->optnum (including 0). Also reject wss.wc >= OSFWSSMAX; nfosfmatchone() already treats that as "should not happen".

Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nfosfmatchone (net/netfilter/nfnetlinkosf.c:98) Call Trace: <IRQ> nfosfmatch (net/netfilter/nfnetlinkosf.c:220) xtosfmatchpacket (net/netfilter/xtosf.c:32) iptdotable (net/ipv4/netfilter/iptables.c:348) nfhookslow (net/netfilter/core.c:622) iplocaldeliver (net/ipv4/ipinput.c:265) iprcv (include/linux/skbuff.h:1162) netifreceiveskbonecore (net/core/dev.c:6181) processbacklog (net/core/dev.c:6642) napipoll (net/core/dev.c:7710) netrxaction (net/core/dev.c:7945) handlesoftirqs (kernel/softirq.c:622)

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

lib/crypto: mpi: Fix integer underflow in mpireadrawfromsgl()

Yiming reports an integer underflow in mpireadrawfromsgl() when subtracting "lzeros" from the unsigned "nbytes".

For this to happen, the scatterlist "sgl" needs to occupy more bytes than the "nbytes" parameter and the first "nbytes + 1" bytes of the scatterlist must be zero. Under these conditions, the while loop iterating over the scatterlist will count more zeroes than "nbytes", subtract the number of zeroes from "nbytes" and cause the underflow.

When commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") originally introduced the bug, it couldn't be triggered because all callers of mpireadrawfromsgl() passed a scatterlist whose length was equal to "nbytes".

However since commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto interface without scatterlists"), the underflow can now actually be triggered. When invoking a KEYCTLPKEYENCRYPT system call with a larger "outlen" than "inlen" and filling the "in" buffer with zeroes, cryptoakciphersyncprep() will create an all-zero scatterlist used for both the "src" and "dst" member of struct akcipherrequest and thereby fulfil the conditions to trigger the bug:

syskeyctl() keyctlpkeyeds() asymmetrickeyedsop() softwarekeyedsop() cryptoakciphersyncencrypt() cryptoakciphersyncprep() cryptoakcipherencrypt() rsaenc() mpireadrawfromsgl()

To the user this will be visible as a DoS as the kernel spins forever, causing soft lockup splats as a side effect.

Fix it.

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

netfilter: nfnetlinklog: initialize nfgenmsg in NLMSGDONE terminator

When batching multiple NFLOG messages (inst->qlen > 1), nfulnlsend() appends an NLMSGDONE terminator with sizeof(struct nfgenmsg) payload via nlmsgput(), but never initializes the nfgenmsg bytes. The nlmsgput() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSGDONE message body.

Use nfnlmsgput() to build the NLMSGDONE terminator, which initializes the nfgenmsg payload via nfnlfillhdr(), consistent with how buildpacketmessage() already constructs NFULNLMSGPACKET headers.

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

nftables: nftdynset: fix possible stateful expression memleak in error path

If cloning the second stateful expression in the element via GFPATOMIC fails, then the first stateful expression remains in place without being released.

unreferenced object (percpu) 0x607b97e9cab8 (size 16):     comm "softirq", pid 0, jiffies 4294931867     hex dump (first 16 bytes on cpu 3):       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     backtrace (crc 0):       pcpuallocnoprof+0x453/0xd80       nftcounterclone+0x9c/0x190 [nftables]       nftexprclone+0x8f/0x1b0 [nftables]       nftdynsetnew+0x2cb/0x5f0 [nftables]       nftrhashupdate+0x236/0x11c0 [nftables]       nftdynseteval+0x11f/0x670 [nftables]       nftdochain+0x253/0x1700 [nftables]       nftdochainipv4+0x18d/0x270 [nftables]       nfhookslow+0xaa/0x1e0       iplocaldeliver+0x209/0x330

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

net: sched: clsapi: fix tcchainfillnode to initialize tcminfo to zero to prevent an info-leak

When building netlink messages, tcchainfillnode() never initializes the tcminfo field of struct tcmsg. Since the allocation is not zeroed, kernel heap memory is leaked to userspace through this 4-byte field.

The fix simply zeroes tcminfo alongside the other fields that are already initialized.

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

netfilter: ctnetlink: zero expect NAT fields when CTAEXPECTNAT absent

ctnetlinkallocexpect() allocates expectations from a non-zeroing slab cache via nfctexpectalloc(). When CTAEXPECTNAT is not present in the netlink message, savedaddr and savedproto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlinkexpdumpexpect(), which checks these fields to decide whether to emit CTAEXPECTNAT.

The safe sibling nfctexpectinit(), used by the packet path, explicitly zeroes these fields.

Zero savedaddr, savedproto and dir in the else branch, guarded by ISENABLED(CONFIGNFNAT) since these fields only exist when NAT is enabled.

Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTAEXPECTNAT, and observing that the ctnetlink dump emits a spurious CTAEXPECTNAT containing stale data from the prior allocation.

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

bridge: brndsend: validate ND option lengths

brndsend() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.

Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.

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

net: ftgmac100: fix ring allocation unwind on open failure

ftgmac100allocrings() allocates rxskbs, txskbs, rxdes, txdes, and rxscratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function.

Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style.

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

xfrmuser: fix info leak in buildreport()

struct xfrmuserreport is a u8 proto field followed by a struct xfrmselector which means there is three "empty" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables.

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

net: rfkill: prevent unlimited numbers of rfkill events from being created

Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a "large" number (i.e. 1000) to prevent abuses like this.

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

mmc: vub300: fix NULL-deref on disconnect

Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.

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

net: bonding: fix NULL deref in bonddebugrlbhashshow

rlbclearslave intentionally keeps RLB hash-table entries on the rxhashtblusedhead list with slave set to NULL when no replacement slave is available. However, bonddebugrlbhashshow visites clientinfo->slave without checking if it's NULL.

Other used-list iterators in bondalb.c already handle this NULL-slave state safely:

- rlbupdateclient returns early on !clientinfo->slave - rlbrequpdateslaveclients, rlbclearslave, and rlbrebalance compare slave values before visiting - lbrequpdatesubnetclients continues if slave is NULL

The following NULL deref crash can be trigger in bonddebugrlbhashshow:

[ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bonddebugrlbhashshow (drivers/net/bonding/bonddebugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seqreaditer (fs/seqfile.c:231) [ 1.296341] seqread (fs/seqfile.c:164) [ 1.296493] fullproxyread (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfsread (fs/readwrite.c:572) [ 1.296981] ksysread (fs/readwrite.c:717) [ 1.297132] dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) [ 1.297325] entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Add a NULL check and print "(none)" for entries with no assigned slave.

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

netfilter: ctnetlink: use netlink policy range checks

Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors.

- CTAPROTOINFOTCPSTATE: reject values > TCPCONNTRACKSYNSENT2 at policy level, removing the manual >= TCPCONNTRACKMAX check. - CTAPROTOINFOTCPWSCALEORIGINAL/REPLY: reject values > TCPMAXWSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count. - CTAFILTERORIGFLAGS/REPLYFLAGS: use NLAPOLICYMASK with CTAFILTERFALL, removing the manual mask checks. - CTAEXPECTFLAGS: use NLAPOLICYMASK with NFCTEXPECTMASK, adding a new mask define grouping all valid expect flags.

Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree.

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

mm/hugememory: fix folio isn't locked in softleaftofolio()

On arm64 server, we found folio that get from migration entry isn't locked in softleaftofolio(). This issue triggers when mTHP splitting and zapnonpresentptes() races, and the root cause is lack of memory barrier in softleaftofolio(). The race is as follows:

CPU0 CPU1

deferredsplitscan() zapnonpresentptes() lock folio splitfolio() unmapfolio() change ptes to migration entries splitfoliotoorder() softleaftofolio() set flags(including PGlocked) for tail pages folio = pfnfolio(softleaftopfn(entry)) smpwmb() VMWARNONONCE(!foliotestlocked(folio)) prepcompoundpage() for tail pages

In splitfoliotoorder(), smpwmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smpwmb() should be paired with smprmb() in softleaftofolio(), which is missed. As a result, if zapnonpresentptes() accesses migration entry that stores tail pfn, softleaftofolio() may see the updated compoundhead of tail page before page->flags.

This issue will trigger VMWARNONONCE() in pfnswapentryfolio() because of the race between folio split and zapnonpresentptes() leading to a folio incorrectly undergoing modification without a folio lock being held.

This is a BUGON() before commit 93976a20345b ("mm: eliminate further swapops predicates"), which in merged in v6.19-rc1.

To fix it, add missing smprmb() if the softleaf entry is migration entry in softleaftofolio() and softleaftopage().

[tujinjiang@huawei.com: update function name and comments]