futex: Prevent lockup in requeue-PI during signal/ timeout wakeup

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

net: qrtr: ns: Limit the maximum server registration per node

Current code does no bound checking on the number of servers added per node. A malicious client can flood NEWSERVER messages and exhaust memory.

Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEWSERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtrnsworker().

Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.

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

net: txgbe: fix RTNL assertion warning when remove module

For the copper NIC with external PHY, the driver called phylinkconnectphy() during probe and phylinkdisconnectphy() during remove. It caused an RTNL assertion warning in phylinkdisconnectphy() upon module remove.

To fix this, add rtnllock() and rtnlunlock() around the phylinkdisconnectphy() in remove function.

------------[ cut here ]------------ RTNL: assertion failed at drivers/net/phy/phylink.c (2351) WARNING: drivers/net/phy/phylink.c:2351 at phylinkdisconnectphy+0xd8/0xf0 [phylink], CPU#0: rmmod/4464 Modules linked in: ... CPU: 0 UID: 0 PID: 4464 Comm: rmmod Kdump: loaded Not tainted 7.0.0-rc4+ Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 RIP: 0010:phylinkdisconnectphy+0xe4/0xf0 [phylink] Code: 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 f6 31 ff e9 3a 38 8f e7 48 8d 3d 48 87 e2 ff ba 2f 09 00 00 48 c7 c6 c1 22 24 c0 <67> 48 0f b9 3a e9 34 ff ff ff 66 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffce7288363ac0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff89654b2a1a00 RCX: 0000000000000000 RDX: 000000000000092f RSI: ffffffffc02422c1 RDI: ffffffffc0239020 RBP: ffffce7288363ae8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8964c4022000 R13: ffff89654fce3028 R14: ffff89654ebb4000 R15: ffffffffc0226348 FS: 0000795e80d93780(0000) GS:ffff896c52857000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005b528b592000 CR3: 0000000170d0f000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: <TASK> txgberemovephy+0xbb/0xd0 [txgbe] txgberemove+0x4c/0xb0 [txgbe] pcideviceremove+0x41/0xb0 deviceremove+0x43/0x80 devicereleasedriverinternal+0x206/0x270 driverdetach+0x4a/0xa0 busremovedriver+0x83/0x120 driverunregister+0x2f/0x60 pciunregisterdriver+0x40/0x90 txgbedriverexit+0x10/0x850 [txgbe] dosysdeletemodule.isra.0+0x1c3/0x2f0 x64sysdeletemodule+0x12/0x20 x64syscall+0x20c3/0x2390 dosyscall64+0x11c/0x1500 ? srsoaliasreturnthunk+0x5/0xfbef5 ? dosyscall64+0x15a/0x1500 ? srsoaliasreturnthunk+0x5/0xfbef5 ? dofault+0x312/0x580 ? srsoaliasreturnthunk+0x5/0xfbef5 ? handlemmfault+0x9d5/0x1040 ? srsoaliasreturnthunk+0x5/0xfbef5 ? countmemcgevents+0x101/0x1d0 ? srsoaliasreturnthunk+0x5/0xfbef5 ? handlemmfault+0x1e8/0x2f0 ? srsoaliasreturnthunk+0x5/0xfbef5 ? douseraddrfault+0x2f8/0x820 ? srsoaliasreturnthunk+0x5/0xfbef5 ? irqentryexit+0xb2/0x600 ? srsoaliasreturnthunk+0x5/0xfbef5 ? excpagefault+0x92/0x1c0 entrySYSCALL64afterhwframe+0x76/0x7e

drm/amdgpu: Limit BO list entry count to prevent resource exhaustion

Bluetooth: L2CAP: Fix null-ptr-deref in l2capsockstatechangecb()

Bluetooth: L2CAP: Fix null-ptr-deref in l2capsockgetsndtimeocb()

Bluetooth: L2CAP: Fix null-ptr-deref in l2capsocknewconnectioncb()

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

net/sched: schred: Replace direct dequeue call with peek and qdiscdequeuepeeked

When red qdisc has children (eg qfq qdisc) whose peek() callback is qdiscpeekdequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gsoskb queue packet. Note: if there wasnt a gsoskb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue.

[ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full) [ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][ T363] RIP: 0010:qfqdequeue+0x446/0xc90 [schqfq] [ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216 [ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048 [ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078 [ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000 [ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200 [ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000 [ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0 [ 78.671585][ T363] PKRU: 55555554 [ 78.671713][ T363] Call Trace: [ 78.671843][ T363] <TASK> [ 78.671936][ T363] ? pfxqfqdequeue+0x10/0x10 [schqfq] [ 78.672148][ T363] ? pfxprintk+0x10/0x10 [ 78.672322][ T363] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 78.672496][ T363] ? lockdephardirqsonprepare+0xa8/0x1a0 [ 78.672706][ T363] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 78.672875][ T363] ? tracehardirqson+0x19/0x1a0 [ 78.673047][ T363] reddequeue+0x65/0x270 [schred] [ 78.673217][ T363] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 78.673385][ T363] tbfdequeue.cold+0xb0/0x70c [schtbf] [ 78.673566][ T363] qdiscrun+0x169/0x1900

The right thing to do in #1b is to grab the skb off gsoskb queue. This patchset fixes that issue by changing #1b to use qdiscdequeuepeeked() method instead.

drm/virtio: Fix driver removal with disabled KMS

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:

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().

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

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

wifi: rtw88: check for PCI upstream bridge existence

pciupstreambridge() returns NULL if the device is on a root bus. If 8821CE is installed in the system with such a PCI topology, the probing routine will crash. This has probably been unnoticed as 8821CE is mostly supplied in laptops where there is a PCI-to-PCI bridge located upstream from the device. However the card might be installed on a system with different configuration.

Check if the bridge does exist for the specific workaround to be applied.

Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.

bpf, sockmap: Fix afunix iter deadlock

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

scsi: target: core: Fix integer overflow in UNMAP bounds check

sbcexecuteunmap() checks LBA + range does not exceed the device capacity, but does not guard against LBA + range wrapping around on 64-bit overflow.

Add an overflow check matching the pattern already used for WRITESAME in the same file.

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]

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.

bpf: Fix NULL deref in mapkptrmatchtype for scalar regs

HID: usbhid: fix deadlock in hidpostreset()

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:

macvlan: fix macvlangetsize() not reserving space for IFLAMACVLANBCCUTOFF

macvlangetsize() does not account for IFLAMACVLANBCCUTOFF, but macvlanfillinfo() conditionally includes it when port->bccutoff != 1. This causes nlaputs32() to fail with -EMSGSIZE when the netlink skb runs out of space, triggering a WARNON in rtnetlink and preventing the interface from being dumped.

The bug can be reproduced with:

ip link add macvlan0 link eth0 type macvlan mode bridge ip link set macvlan0 type macvlan bccutoff 0 ip -d link show macvlan0 # fails with -EMSGSIZE

The bccutoff feature was added in commit 954d1fa1ac93 ("macvlan: Add netlink attribute for broadcast cutoff"), which added the nlaputs32() call in macvlanfillinfo() but missed adding the corresponding nlatotalsize(4) in macvlangetsize(). A follow-up commit 55cef78c244d ("macvlan: add forgotten nlapolicy for IFLAMACVLANBCCUTOFF") fixed the missing nlapolicy entry but still did not fix the size calculation.

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

net/sched: netem: fix queue limit check to include reordered packets

The queue limit check in netemenqueue() uses q->tlen which only counts packets in the internal tfifo. Packets placed in sch->q by the reorder path (qdiscenqueuehead) are not counted, allowing the total queue occupancy to exceed sch->limit under reordering.

Include sch->q.qlen in the limit check.

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

netdevsim: zero initialize struct iphdr in dummy skbuff

Syzbot reports a KMSAN uninit-value originating from nsimdevtrapskbbuild, with the allocation also being performed in the same function.

Fix this by calling skbputzero instead of skbput to guarantee zero initialization of the whole IP header.