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.

hsr: Remove WARNONCE() in hsraddrisself().

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.

drm/virtio: Fix driver removal with disabled KMS

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

net: bonding: fix NULL pointer dereference in bonddoioctl()

In bonddoioctl(), slavedev is obtained via devgetbyname() which can return NULL if the requested interface name does not exist. However, the subsequent slavedbg() call is placed before the NULL check:

slavedev = devgetbyname(net, ifr->ifrslave); slavedbg(bonddev, slavedev, "slavedev=%p:\n", slavedev); //here if (!slavedev) return -ENODEV;

The slavedbg() macro expands to netdevdbg(bonddev, "(slave %s): " fmt, (slavedev)->name, ...) which unconditionally dereferences slavedev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name.

This is reachable from userspace via the bonding ioctl interface with CAPNETADMIN capability, making it a potential local denial-of-service vector.

Fix by moving the slavedbg() call after the NULL check.

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

padata: Put CPU offline callback in ONLINE section to allow failure

syzbot reported the following warning:

DEAD callback error for CPU1 WARNING: kernel/cpu.c:1463 at cpudown+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614

at commit 4ae12d8bd9a8 ("Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux") which tglx traced to padatacpudead() given it's the only sub-CPUHPTEARDOWNCPU callback that returns an error.

Failure isn't allowed in hotplug states before CPUHPTEARDOWNCPU so move the CPU offline callback to the ONLINE section where failure is possible.

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

scsi: sg: Resolve soft lockup issue when opening /dev/sgX

The parameter defreservedsize defines the default buffer size reserved for each Sgfd and should be restricted to a range between 0 and 1,048,576 (see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the function sgprocwritedressz enforces this limit, it is possible to bypass it by directly modifying the module parameter as shown below, which then causes a soft lockup:

echo -1 > /sys/module/sg/parameters/defreservedsize exec 4<> /dev/sg0

watchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537] Modules loaded: CPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134, PREEMPT disabled Hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version 1.16.1-2.fc37 dated 04/01/2014 ... Call Trace:

sgbuildreserve+0x5c/0xa0 sgaddsfp+0x168/0x270 sgopen+0x16e/0x340 chrdevopen+0xbe/0x230 dodentryopen+0x175/0x480 vfsopen+0x34/0xf0 doopen+0x265/0x3d0 pathopenat+0x110/0x290 dofilpopen+0xc3/0x170 dosysopenat2+0x71/0xe0 x64sysopenat+0x6d/0xa0 dosyscall64+0x62/0x310 entrySYSCALL64afterhwframe+0x76/0x7e

The fix is to use moduleparamcb to validate and reject invalid values assigned to defreservedsize.

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.

drm/amdgpu: fix AMDGPUINFOREADMMRREG

ALSA: hda/conexant: Fix missing error check for jack detection

ice: fix NULL pointer dereference in iceresetallvfs()

audit: fix incorrect inheritable capability in CAPSET records

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.

drbd: Balance RCU calls in drbdadmdumpdevices()

blk-cgroup: fix disk reference leak in blkcgmaybethrottlecurrent()

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

wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irqpreparebcntasklet

The irqpreparebcntasklet is initialized in rtlpciinit() and scheduled when RTLIMRBCNINT interrupt is triggered by hardware. But it is never killed in rtlpcideinit(). When the rtlwifi card probe fails or is being detached, the ieee80211hw is deallocated. However, irqpreparebcntasklet may still be running or pending, leading to use-after-free when the freed ieee80211hw is accessed in rtlpcipreparebcntasklet().

Similar to irqtasklet, add taskletkill() in rtlpcideinit() to ensure that irqpreparebcntasklet is properly terminated before the ieee80211hw is released.

The issue was identified through static analysis.

bpf: testrun: Fix the null pointer dereference issue in bpflwtxmitpushencap

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

wifi: brcmfmac: Fix error pointer dereference

The function brcmfchipaddcore() can return an error pointer and is not checked. Add checks for error pointer.

Detected by Smatch: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1010 brcmfchiprecognition() error: 'core' dereferencing possible ERRPTR()

drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1013 brcmfchiprecognition() error: 'core' dereferencing possible ERRPTR()

drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1016 brcmfchiprecognition() error: 'core' dereferencing possible ERRPTR()

drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1019 brcmfchiprecognition() error: 'core' dereferencing possible ERRPTR()

drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1022 brcmfchiprecognition() error: 'core' dereferencing possible ERRPTR()

[add missing wifi: prefix]

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

net: hamradio: 6pack: fix uninit-value in sixpackreceivebuf

sixpackreceivebuf() does not properly skip bytes with TTY error flags. The while loop iterates through the flags buffer but never advances the data pointer (cp), and passes the original count (including error bytes) to sixpackdecode(). This causes sixpackdecode() to process bytes that should have been skipped due to TTY errors. The TTY layer does not guarantee that cp[i] holds a meaningful value when fp[i] is set, so passing those positions to sixpackdecode() results in KMSAN reporting an uninit-value read.

Fix this by processing bytes one at a time, advancing cp on each iteration, and only passing valid (non-error) bytes to sixpackdecode(). This matches the pattern used by slipreceivebuf() and mkissreceivebuf() for the same purpose.

bpf: reject short IPv4/IPv6 inputs in bpfprogtestrunskb

drm/sun4i: backend: fix error pointer dereference

dm cache: fix dirty mapping checking in passthrough mode switching

dm cache metadata: fix memory leak on metadata abort retry

drm/bridge: cadence: cdns-mhdp8546-core: Set the mhdp connector earlier in atomicenable()

drm/msm/dpu: fix mismatch between power and frequency

efi/capsule-loader: fix incorrect sizeof in phys array reallocation

HID: usbhid: fix deadlock in hidpostreset()

bpf, sockmap: Fix afunix iter deadlock

bpf: Fix NULL deref in mapkptrmatchtype for scalar regs

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

platform/x86: dell-wmi-sysman: bound enumeration string aggregation

populateenumdata() aggregates firmware-provided value-modifier and possible-value strings into fixed 512-byte struct members. The current code bounds each individual source string but then appends every string and separator with raw strcat() and no remaining-space check.

Switch the aggregation loops to a bounded append helper and reject enumeration packages whose combined strings do not fit in the destination buffers.

[ij: add include]