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

xfrmuser: fix info leak in buildmapping()

struct xfrmusersaid has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.

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:

netfilter: xtmultiport: validate range encoding in checkentry

portsmatchv1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end.

The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving portsmatchv1() to step past the last valid ports[] element while interpreting the rule.

Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.

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:

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:

mptcp: fix slab-use-after-free in inetlookupestablished

The ehash table lookups are lockless and rely on SLABTYPESAFEBYRCU to guarantee socket memory stability during RCU read-side critical sections. Both tcpprot and tcpv6prot have their slab caches created with this flag via protoregister().

However, MPTCP's mptcpsubflowinit() copies tcpv6prot into tcpv6protoverride during inetinit() (fsinitcall, level 5), before inet6init() (moduleinit/deviceinitcall, level 6) has called protoregister(&tcpv6prot). At that point, tcpv6prot.slab is still NULL, so tcpv6protoverride.slab remains NULL permanently.

This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLABTYPESAFEBYRCU, so when these sockets are freed without SOCKRCUFREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcureadlock can then access freed memory, triggering a slab-use-after-free in inetlookupestablished.

Fix this by splitting the IPv6-specific initialization out of mptcpsubflowinit() into a new mptcpsubflowv6init(), called from mptcpprotov6init() before protocol registration. This ensures tcpv6protoverride.slab correctly inherits the SLABTYPESAFEBYRCU slab cache.

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

netfilter: nftct: fix use-after-free in timeout object destroy

nftcttimeoutobjdestroy() frees the timeout object with kfree() immediately after nfctuntimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcudereference() in nfcttimeoutdata().

Add an rcuhead to struct nfcttimeout and use kfreercu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlinkcttimeout.c.

KASAN report: BUG: KASAN: slab-use-after-free in nfconntracktcppacket+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80

Call Trace: nfconntracktcppacket+0x1381/0x29d0 nfconntrackin+0x612/0x8b0 nfhookslow+0x70/0x100 iplocalout+0x1b2/0x210 tcpsendmsglocked+0x722/0x1580 syssendto+0x2d8/0x320

Allocated by task 75: nftcttimeoutobjinit+0xf6/0x290 nftobjinit+0x107/0x1b0 nftablesnewobj+0x680/0x9c0 nfnetlinkrcvbatch+0xc29/0xe00

Freed by task 26: nftobjdestroy+0x3f/0xa0 nftablestransdestroywork+0x51c/0x5c0 processonework+0x2c4/0x5a0

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

xfrm: clear trailing padding in buildpolexpire()

buildexpire() clears the trailing padding bytes of struct xfrmuserexpire after setting the hard field via memsetafter(), but the analogous function buildpolexpire() does not do this for struct xfrmuserpolexpire.

The padding bytes after the u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRPEXPIRE listeners, leaking kernel heap memory contents.

Add the missing memsetafter() call, matching buildexpire().

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

net: altera-tse: fix skb leak on DMA mapping error in tsestartxmit()

When dmamapsingle() fails in tsestartxmit(), the function returns NETDEVTXOK without freeing the skb. Since NETDEVTXOK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure.

Add devkfreeskbany() before returning to properly free the skb.

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: stmmac: fix integer underflow in chain mode

The jumbofrm() chain-mode implementation unconditionally computes

len = nopagedlen - bmax;

where nopagedlen = skbheadlen(skb) (linear bytes only) and bmax is BUFSIZE8KiB or BUFSIZE2KiB. However, the caller stmmacxmit() decides to invoke jumbofrm() based on skb->len (total length including page fragments):

isjumbo = stmmacisjumbofrm(priv, skb->len, enhdesc);

When a packet has a small linear portion (nopagedlen <= bmax) but a large total length due to page fragments (skb->len > bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx). This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb->data + bmax i pointers far beyond the skb buffer to dmamapsingle(). On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware.

Fix this by introducing a buflen local variable clamped to min(nopagedlen, bmax). Computing len = nopagedlen - buflen is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmacxmit() handles page fragments afterward.

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

rxrpc: fix reference count leak in rxrpcserverkeyring()

This patch fixes a reference count leak in rxrpcserverkeyring() by checking if rx->securities is already set.

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

RDMA/irdma: Fix deadlock during netdev reset with active connections

Resolve deadlock that occurs when user executes netdev reset while RDMA applications (e.g., rping) are active. The netdev reset causes ice driver to remove irdma auxiliary driver, triggering devicedelete and subsequent client removal. During client removal, uverbsclient waits for QP reference count to reach zero while cmaclient holds the final reference, creating circular dependency and indefinite wait in iWARP mode. Skip QP reference count wait during device reset to prevent deadlock.

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

net: macb: Use devconsumeskbany() to free TX SKBs

The napiconsumeskb() function is not intended to be called in an IRQ disabled context. However, after commit 6bc8a5098bf4 ("net: macb: Fix txptrlock locking"), the freeing of TX SKBs is performed with IRQs disabled. To resolve the following call trace, use devconsumeskbany() for freeing TX SKBs: WARNING: kernel/softirq.c:430 at localbhenableip+0x174/0x188, CPU#0: ksoftirqd/0/15 Modules linked in: CPU: 0 UID: 0 PID: 15 Comm: ksoftirqd/0 Not tainted 7.0.0-rc4-next-20260319-yocto-standard-dirty #37 PREEMPT Hardware name: ZynqMP ZCU102 Rev1.1 (DT) pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : localbhenableip+0x174/0x188 lr : localbhenable+0x24/0x38 sp : ffff800082b3bb10 x29: ffff800082b3bb10 x28: ffff0008031f3c00 x27: 000000000011ede0 x26: ffff000800a7ff00 x25: ffff800083937ce8 x24: 0000000000017a80 x23: ffff000803243a78 x22: 0000000000000040 x21: 0000000000000000 x20: ffff000800394c80 x19: 0000000000000200 x18: 0000000000000001 x17: 0000000000000001 x16: ffff000803240000 x15: 0000000000000000 x14: ffffffffffffffff x13: 0000000000000028 x12: ffff000800395650 x11: ffff8000821d1528 x10: ffff800081c2bc08 x9 : ffff800081c1e258 x8 : 0000000100000301 x7 : ffff8000810426ec x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000008 x1 : 0000000000000200 x0 : ffff8000810428dc Call trace: localbhenableip+0x174/0x188 (P) localbhenable+0x24/0x38 skbattemptdeferfree+0x190/0x1d8 napiconsumeskb+0x58/0x108 macbtxpoll+0x1a4/0x558 napipoll+0x50/0x198 netrxaction+0x1f4/0x3d8 handlesoftirqs+0x16c/0x560 runksoftirqd+0x44/0x80 smpbootthreadfn+0x1d8/0x338 kthread+0x120/0x150 retfromfork+0x10/0x20 irq event stamp: 29751 hardirqs last enabled at (29750): [<ffff8000813be184>] rawspinunlockirqrestore+0x44/0x88 hardirqs last disabled at (29751): [<ffff8000813bdf60>] rawspinlockirqsave+0x38/0x98 softirqs last enabled at (29150): [<ffff8000800f1aec>] handlesoftirqs+0x504/0x560 softirqs last disabled at (29153): [<ffff8000800f2fec>] runksoftirqd+0x44/0x80

futex: Clear stale exiting pointer in futexlockpi() retry path

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:

net/tls: fix use-after-free in -EBUSY error path of tlsdoencryption

The -EBUSY handling in tlsdoencryption(), introduced by commit 859054147318 ("net: tls: handle backlogging of crypto requests"), has a use-after-free due to double cleanup of encryptpending and the scatterlist entry.

When cryptoaeadencrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tlsencryptdone() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encryptpending. However, if tlsencryptasyncwait() returns an error, the synchronous error path in tlsdoencryption() performs the same cleanup again, double-decrementing encryptpending and double-restoring the scatterlist.

The double-decrement corrupts the encryptpending sentinel (initialized to 1), making tlsencryptasyncwait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tlsrec via bpfexectxverdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record.

Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encryptpending and sge restoration.

esp: fix skb leak with espintcp and async crypto

afkey: validate families in pfkeysendmigrate()

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

net: openvswitch: Avoid releasing netdev before teardown completes

The patch cited in the Fixes tag below changed the teardown code for OVS ports to no longer unconditionally take the RTNL. After this change, the netdevdestroy() callback can proceed immediately to the callrcu() invocation if the IFFOVSDATAPATH flag is already cleared on the netdev.

The ovsnetdevdetachdev() function clears the flag before completing the unregistration, and if it gets preempted after clearing the flag (as can happen on an -rt kernel), netdevdestroy() can complete and the device can be freed before the unregistration completes. This leads to a splat like:

[ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el102.x8664+rt #1 PREEMPTRT [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025 [ 998.393889] RIP: 0010:devsetpromiscuity+0x8d/0xa0 [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90 [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246 [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000 [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05 [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000 [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006 [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000 [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000 [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0 [ 998.393944] PKRU: 55555554 [ 998.393946] Call Trace: [ 998.393949] <TASK> [ 998.393952] ? showtraceloglvl+0x1b0/0x2f0 [ 998.393961] ? showtraceloglvl+0x1b0/0x2f0 [ 998.393975] ? dpdeviceevent+0x41/0x80 [openvswitch] [ 998.394009] ? diebody.cold+0x8/0x12 [ 998.394016] ? dieaddr+0x3c/0x60 [ 998.394027] ? excgeneralprotection+0x16d/0x390 [ 998.394042] ? asmexcgeneralprotection+0x26/0x30 [ 998.394058] ? devsetpromiscuity+0x8d/0xa0 [ 998.394066] ? ovsnetdevdetachdev+0x3a/0x80 [openvswitch] [ 998.394092] dpdeviceevent+0x41/0x80 [openvswitch] [ 998.394102] notifiercallchain+0x5a/0xd0 [ 998.394106] unregisternetdevicemanynotify+0x51b/0xa60 [ 998.394110] rtnldellink+0x169/0x3e0 [ 998.394121] ? rtmutexslowlock.constprop.0+0x95/0xd0 [ 998.394125] rtnetlinkrcvmsg+0x142/0x3f0 [ 998.394128] ? avchaspermnoaudit+0x69/0xf0 [ 998.394130] ? pfxrtnetlinkrcvmsg+0x10/0x10 [ 998.394132] netlinkrcvskb+0x50/0x100 [ 998.394138] netlinkunicast+0x292/0x3f0 [ 998.394141] netlinksendmsg+0x21b/0x470 [ 998.394145] syssendmsg+0x39d/0x3d0 [ 998.394149] syssendmsg+0x9a/0xe0 [ 998.394156] syssendmsg+0x7a/0xd0 [ 998.394160] dosyscall64+0x7f/0x170 [ 998.394162] entrySYSCALL64afterhwframe+0x76/0x7e [ 998.394165] RIP: 0033:0x7fad61bf4724 [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIGRAX: 000000000000002e [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724 [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003 [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2 ---truncated---

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

net/smc: fix double-free of smcspdpriv when tee() duplicates splice pipe buffer

smcrxsplice() allocates one smcspdpriv per pipebuffer and stores the pointer in pipebuffer.private. The pipebufoperations for these buffers used .get = genericpipebufget, which only increments the page reference count when tee(2) duplicates a pipe buffer. The smcspdpriv pointer itself was not handled, so after tee() both the original and the cloned pipebuffer share the same smcspdpriv .

When both pipes are subsequently released, smcrxpipebufrelease() is called twice against the same object:

1st call: kfree(priv) sockput(sk) smcrxupdatecons() [correct] 2nd call: kfree(priv) sockput(sk) smcrxupdatecons() [UAF]

KASAN reports a slab-use-after-free in smcrxpipebufrelease(), which then escalates to a NULL-pointer dereference and kernel panic via smcrxupdateconsumer() when it chases the freed priv->smc pointer:

BUG: KASAN: slab-use-after-free in smcrxpipebufrelease+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smcsplicetee/74 Call Trace: <TASK> dumpstacklvl+0x53/0x70 printreport+0xce/0x650 kasanreport+0xc6/0x100 smcrxpipebufrelease+0x78/0x2a0 freepipeinfo+0xd4/0x130 piperelease+0x142/0x160 fput+0x1c6/0x490 x64sysclose+0x4f/0x90 dosyscall64+0xa6/0x1a0 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smcrxupdateconsumer+0x8d/0x350 Call Trace: <TASK> smcrxpipebufrelease+0x121/0x2a0 freepipeinfo+0xd4/0x130 piperelease+0x142/0x160 fput+0x1c6/0x490 x64sysclose+0x4f/0x90 dosyscall64+0xa6/0x1a0 entrySYSCALL64afterhwframe+0x77/0x7f </TASK> Kernel panic - not syncing: Fatal exception

Beyond the memory-safety problem, duplicating an SMC splice buffer is semantically questionable: smcrxupdatecons() would advance the consumer cursor twice for the same data, corrupting receive-window accounting. A refcount on smcspdpriv could fix the double-free, but the cursor-accounting issue would still need to be addressed separately.

The .get callback is invoked by both tee(2) and splicepipetopipe() for partial transfers; both will now return -EFAULT. Users who need to duplicate SMC socket data must use a copy-based read path.

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

net: fix fanout UAF in packetrelease() via NETDEVUP race

packetrelease() has a race window where NETDEVUP can re-register a socket into a fanout group's arr[] array. The re-registration is not cleaned up by fanoutrelease(), leaving a dangling pointer in the fanout array. packetrelease() does NOT zero po->num in its bindlock section. After releasing bindlock, po->num is still non-zero and po->ifindex still matches the bound device. A concurrent packetnotifier(NETDEVUP) that already found the socket in sklist can re-register the hook. For fanout sockets, this re-registration calls fanoutlink(sk, po) which adds the socket back into f->arr[] and increments f->nummembers, but does NOT increment f->skref.

The fix sets po->num to zero in packetrelease while bindlock is held to prevent NETDEVUP from linking, preventing the race window.

This bug was found following an additional audit with Claude Code based on CVE-2025-38617.

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

udp: Fix wildcard bind conflict check when using hash2

When binding a udpsock to a local address and port, UDP uses two hashes (udptable->hash and udptable->hash2) for collision detection. The current code switches to "hash2" when hslot->count > 10.

"hash2" is keyed by local address and local port. "hash" is keyed by local port only.

The issue can be shown in the following bind sequence (pseudo code):

bind(fd1, "[fd00::1]:8888") bind(fd2, "[fd00::2]:8888") bind(fd3, "[fd00::3]:8888") bind(fd4, "[fd00::4]:8888") bind(fd5, "[fd00::5]:8888") bind(fd6, "[fd00::6]:8888") bind(fd7, "[fd00::7]:8888") bind(fd8, "[fd00::8]:8888") bind(fd9, "[fd00::9]:8888") bind(fd10, "[fd00::10]:8888")

/ Correctly return -EADDRINUSE because "hash" is used instead of "hash2". udpliblportinuse() detects the conflict. / bind(failfd, "[::]:8888")

/ After one more socket is bound to "[fd00::11]:8888", hslot->count exceeds 10 and "hash2" is used instead. / bind(fd11, "[fd00::11]:8888") bind(failfd, "[::]:8888") / succeeds unexpectedly /

The same issue applies to the IPv4 wildcard address "0.0.0.0" and the IPv4-mapped wildcard address "::ffff:0.0.0.0". For example, if there are existing sockets bound to "192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or "[::ffff:0.0.0.0]:8888" can also miss the conflict when hslot->count > 10.

TCP inetcskgetport() already has the correct check in inetusebhash2onbind(). Rename it to inetusehash2onbind() and move it to inethashtables.h so udp.c can reuse it in this fix.

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

netfilter: nfconntrackexpect: skip expectations in other netns via proc

Skip expectations that do not reside in this netns.

Similar to e77e6ff502ea ("netfilter: conntrack: do not dump other netns's conntrack entries via proc").

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:

net: macb: use the current queue number for stats

There's a potential mismatch between the memory reserved for statistics and the amount of memory written.

gemgetssetcount() correctly computes the number of stats based on the active queues, whereas gemgetethtoolstats() indiscriminately copies data using the maximum number of queues, and in the case the number of active queues is less than MACBMAXQUEUES, this results in a OOB write as observed in the KASAN splat.

================================================================== BUG: KASAN: vmalloc-out-of-bounds in gemgetethtoolstats+0x54/0x78 [macb] Write of size 760 at addr ffff80008080b000 by task ethtool/1027

CPU: [...] Tainted: [E]=UNSIGNEDMODULE Hardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025 Call trace: showstack+0x20/0x38 (C) dumpstacklvl+0x80/0xf8 printreport+0x384/0x5e0 kasanreport+0xa0/0xf0 kasancheckrange+0xe8/0x190 asanmemcpy+0x54/0x98 gemgetethtoolstats+0x54/0x78 [macb 926c13f3af83b0c6fe64badb21ec87d5e93fcf65] devethtool+0x1220/0x38c0 devioctl+0x4ac/0xca8 sockdoioctl+0x170/0x1d8 sockioctl+0x484/0x5d8 arm64sysioctl+0x12c/0x1b8 invokesyscall+0xd4/0x258 el0svccommon.constprop.0+0xb4/0x240 doel0svc+0x48/0x68 el0svc+0x40/0xf8 el0t64synchandler+0xa0/0xe8 el0t64sync+0x1b0/0x1b8

The buggy address belongs to a 1-page vmalloc region starting at 0xffff80008080b000 allocated at devethtool+0x11f0/0x38c0 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff00000a333000 pfn:0xa333 flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff) raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ==================================================================

Fix it by making sure the copied size only considers the active number of queues.

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

spi: spi-fsl-lpspi: fix teardown order issue (UAF)

There is a teardown order issue in the driver. The SPI controller is registered using devmspiregistercontroller(), which delays unregistration of the SPI controller until after the fsllpspiremove() function returns.

As the fsllpspiremove() function synchronously tears down the DMA channels, a running SPI transfer triggers the following NULL pointer dereference due to use after free:

| fsllpspi 42550000.spi: I/O Error in DMA RX | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] | Call trace: | fsllpspidmatransfer+0x260/0x340 [spifsllpspi] | fsllpspitransferone+0x198/0x448 [spifsllpspi] | spitransferonemessage+0x49c/0x7c8 | spipumptransfermessage+0x120/0x420 | spisync+0x2c4/0x520 | spisync+0x34/0x60 | spidevmessage+0x20c/0x378 [spidev] | spidevioctl+0x398/0x750 [spidev] [...]

Switch from devmspiregistercontroller() to spiregistercontroller() in fsllpspiprobe() and add the corresponding spiunregistercontroller() in fsllpspiremove().

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

netfilter: nfnetlinklog: account for netlink header size

This is a followup to an old bug fix: NLMSGDONE needs to account for the netlink header size, not just the attribute size.

This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.

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

ipv6: avoid overflows in ip6datagramsendctl()

Yiming Qian reported : <quote> I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via skbunderpanic() (local DoS).

The core issue is a mismatch between:

- a 16-bit length accumulator (struct ipv6txoptions::optflen, type u16) and - a pointer to the last provided destination-options header (opt->dst1opt)

when multiple IPV6DSTOPTS control messages (cmsgs) are provided.

- include/net/ipv6.h: - struct ipv6txoptions::optflen is u16 (wrap possible). (lines 291-307, especially 298) - net/ipv6/datagram.c:ip6datagramsendctl(): - Accepts repeated IPV6DSTOPTS and accumulates into optflen without rejecting duplicates. (lines 909-933) - net/ipv6/ip6output.c:ip6appenddata(): - Uses opt->optflen + opt->optnflen to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) - net/ipv6/ip6output.c:ip6makeskb(): - Calls ipv6pushfragopts() if opt->optflen is non-zero. (lines 1930-1934) - net/ipv6/exthdrs.c:ipv6pushfragopts() / ipv6pushexthdr(): - Push size comes from ipv6optlen(opt->dst1opt) (based on the pointed-to header). (lines 1179-1185 and 1206-1211)

1. optflen is a 16-bit accumulator:

- include/net/ipv6.h:298 defines u16 optflen; / after fragment hdr /.

2. ip6datagramsendctl() accepts repeated IPV6DSTOPTS cmsgs and increments optflen each time:

- In net/ipv6/datagram.c:909-933, for IPV6DSTOPTS: - It computes len = ((hdr->hdrlen + 1) << 3); - It checks CAPNETRAW using nscapable(net->userns, CAPNETRAW). (line 922) - Then it does: - opt->optflen += len; (line 927) - opt->dst1opt = hdr; (line 928)

There is no duplicate rejection here (unlike the legacy IPV62292DSTOPTS path which rejects duplicates at net/ipv6/datagram.c:901-904).

If enough large IPV6DSTOPTS cmsgs are provided, optflen wraps while dst1opt still points to a large (2048-byte) destination-options header.

In the attached PoC (poc.c):

- 32 cmsgs with hdrlen=255 => len = (255+1)8 = 2048 - 1 cmsg with hdrlen=0 => len = 8 - Total increment: 322048 + 8 = 65544, so (u16)optflen == 8 - The last cmsg is 2048 bytes, so dst1opt points to a 2048-byte header.

3. The transmit path sizes headers using the wrapped optflen:

- In net/ipv6/ip6output.c:1463-1465: - headersize = sizeof(struct ipv6hdr) + (opt ? opt->optflen + opt->optnflen : 0) + ...;

With wrapped optflen, headersize/headroom decisions underestimate what will be pushed later.

4. When building the final skb, the actual push length comes from dst1opt and is not limited by wrapped optflen:

- In net/ipv6/ip6output.c:1930-1934: - if (opt->optflen) proto = ipv6pushfragopts(skb, opt, proto); - In net/ipv6/exthdrs.c:1206-1211, ipv6pushfragopts() pushes dst1opt via ipv6pushexthdr(). - In net/ipv6/exthdrs.c:1179-1184, ipv6pushexthdr() does: - skbpush(skb, ipv6optlen(opt)); - memcpy(h, opt, ipv6optlen(opt));

With insufficient headroom, skbpush() underflows and triggers skbunderpanic() -> BUG():

- net/core/skbuff.c:2669-2675 (skbpush() calls skbunderpanic()) - net/core/skbuff.c:207-214 (skbpanic() ends in BUG())

- The IPV6DSTOPTS cmsg path requires CAPNETRAW in the target netns user namespace (nscapable(net->userns, CAPNETRAW)). - Root (or any task with CAPNETRAW) can trigger this without user namespaces. - An unprivileged uid=1000 user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced CAPNETRAW (the attached PoC does this).

- Local denial of service: kernel BUG/panic (system crash). - ---truncated---