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

ksmbd: fix use-after-free in durable v2 replay of active file handles

parsedurablehandlecontext() unconditionally assigns dhinfo->fp->conn to the current connection when handling a DURABLEREQV2 context with SMB2FLAGSREPLAYOPERATION. ksmbdlookupfdcguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, ksmbdclosefd() dereferences the stale fp->conn via spinlock(&fp->conn->llistlock), causing a use-after-free.

KASAN report:

[ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in rawspinlock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 7.350070] Workqueue: ksmbd-io handleksmbdwork [ 7.350083] Call Trace: [ 7.350087] <TASK> [ 7.350087] dumpstacklvl+0x64/0x80 [ 7.350094] printreport+0xce/0x660 [ 7.350100] ? pfxrawspinlockirqsave+0x10/0x10 [ 7.350101] ? pfxmodtimer+0x10/0x10 [ 7.350106] ? rawspinlock+0x75/0xe0 [ 7.350108] kasanreport+0xce/0x100 [ 7.350109] ? rawspinlock+0x75/0xe0 [ 7.350114] kasancheckrange+0x105/0x1b0 [ 7.350116] rawspinlock+0x75/0xe0 [ 7.350118] ? pfxrawspinlock+0x10/0x10 [ 7.350119] ? callrcucommon.constprop.0+0x25e/0x780 [ 7.350125] ? closeiddeloplock+0x2cc/0x4e0 [ 7.350128] ksmbdclosefd+0x27f/0xaf0 [ 7.350131] ksmbdclosefd+0x135/0x1b0 [ 7.350133] smb2close+0xb19/0x15b0 [ 7.350142] ? pfxsmb2close+0x10/0x10 [ 7.350143] ? xasload+0x18/0x270 [ 7.350146] ? rawspinlock+0x84/0xe0 [ 7.350148] ? pfxrawspinlock+0x10/0x10 [ 7.350150] ? rawspinunlock+0xe/0x30 [ 7.350151] ? ksmbdsmb2checkmessage+0xeb2/0x24c0 [ 7.350153] ? ksmbdtreeconnlookup+0xcd/0xf0 [ 7.350154] handleksmbdwork+0x40f/0x1080 [ 7.350156] processonework+0x5fa/0xef0 [ 7.350162] ? assignwork+0x122/0x3e0 [ 7.350163] workerthread+0x54b/0xf70 [ 7.350165] ? pfxworkerthread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalcsigpending+0x19b/0x230 [ 7.350176] ? pfxkthread+0x10/0x10 [ 7.350178] retfromfork+0x4fb/0x6c0 [ 7.350183] ? pfxretfromfork+0x10/0x10 [ 7.350185] ? switchto+0x36c/0xbe0 [ 7.350188] ? pfxkthread+0x10/0x10 [ 7.350190] retfromforkasm+0x1a/0x30 [ 7.350197] </TASK> [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasansavestack+0x33/0x60 [ 7.355373] kasansavetrack+0x14/0x30 [ 7.355484] kasankmalloc+0x8f/0xa0 [ 7.355593] ksmbdconnalloc+0x44/0x6d0 [ 7.355711] ksmbdkthreadfn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] retfromfork+0x4fb/0x6c0 [ 7.356051] retfromforkasm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasansavestack+0x33/0x60 [ 7.356416] kasansavetrack+0x14/0x30 [ 7.356527] kasansavefreeinfo+0x3b/0x60 [ 7.356646] kasanslabfree+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbdtcpdisconnect+0x59/0xe0 [ 7.356993] ksmbdconnhandlerloop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] retfromfork+0x4fb/0x6c0 [ 7.357350] retfromforkasm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---

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

ksmbd: fix use-after-free of shareconf in compound request

smb2getksmbdtcon() reuses work->tcon in compound requests without validating tcon->tstate. ksmbdtreeconnlookup() checks tstate == TREECONNECTED on the initial lookup path, but the compound reuse path bypasses this check entirely.

If a prior command in the compound (SMB2TREEDISCONNECT) sets tstate to TREEDISCONNECTED and frees shareconf via ksmbdshareconfigput(), subsequent commands dereference the freed shareconf through work->tcon->shareconf.

KASAN report:

[ 4.144653] ================================================================== [ 4.145059] BUG: KASAN: slab-use-after-free in smb2write+0xc74/0xe70 [ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44 [ 4.145772] [ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY [ 4.145871] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 4.145875] Workqueue: ksmbd-io handleksmbdwork [ 4.145888] Call Trace: [ 4.145892] <TASK> [ 4.145894] dumpstacklvl+0x64/0x80 [ 4.145910] printreport+0xce/0x660 [ 4.145919] ? pfxrawspinlockirqsave+0x10/0x10 [ 4.145928] ? smb2write+0xc74/0xe70 [ 4.145931] kasanreport+0xce/0x100 [ 4.145934] ? smb2write+0xc74/0xe70 [ 4.145937] smb2write+0xc74/0xe70 [ 4.145939] ? pfxsmb2write+0x10/0x10 [ 4.145942] ? rawspinunlock+0xe/0x30 [ 4.145945] ? ksmbdsmb2checkmessage+0xeb2/0x24c0 [ 4.145948] ? smb2treedisconnect+0x31c/0x480 [ 4.145951] handleksmbdwork+0x40f/0x1080 [ 4.145953] processonework+0x5fa/0xef0 [ 4.145962] ? assignwork+0x122/0x3e0 [ 4.145964] workerthread+0x54b/0xf70 [ 4.145967] ? pfxworkerthread+0x10/0x10 [ 4.145970] kthread+0x346/0x470 [ 4.145976] ? recalcsigpending+0x19b/0x230 [ 4.145980] ? pfxkthread+0x10/0x10 [ 4.145984] retfromfork+0x4fb/0x6c0 [ 4.145992] ? pfxretfromfork+0x10/0x10 [ 4.145995] ? switchto+0x36c/0xbe0 [ 4.145999] ? pfxkthread+0x10/0x10 [ 4.146003] retfromforkasm+0x1a/0x30 [ 4.146013] </TASK> [ 4.146014] [ 4.149858] Allocated by task 44: [ 4.149953] kasansavestack+0x33/0x60 [ 4.150061] kasansavetrack+0x14/0x30 [ 4.150169] kasankmalloc+0x8f/0xa0 [ 4.150274] ksmbdshareconfigget+0x1dd/0xdd0 [ 4.150401] ksmbdtreeconnconnect+0x7e/0x600 [ 4.150529] smb2treeconnect+0x2e6/0x1000 [ 4.150645] handleksmbdwork+0x40f/0x1080 [ 4.150761] processonework+0x5fa/0xef0 [ 4.150873] workerthread+0x54b/0xf70 [ 4.150978] kthread+0x346/0x470 [ 4.151071] retfromfork+0x4fb/0x6c0 [ 4.151176] retfromforkasm+0x1a/0x30 [ 4.151286] [ 4.151332] Freed by task 44: [ 4.151418] kasansavestack+0x33/0x60 [ 4.151526] kasansavetrack+0x14/0x30 [ 4.151634] kasansavefreeinfo+0x3b/0x60 [ 4.151751] kasanslabfree+0x43/0x70 [ 4.151861] kfree+0x1ca/0x430 [ 4.151952] ksmbdtreeconndisconnect+0xc8/0x190 [ 4.152088] smb2treedisconnect+0x1cd/0x480 [ 4.152211] handleksmbdwork+0x40f/0x1080 [ 4.152326] processonework+0x5fa/0xef0 [ 4.152438] workerthread+0x54b/0xf70 [ 4.152545] kthread+0x346/0x470 [ 4.152638] retfromfork+0x4fb/0x6c0 [ 4.152743] retfromforkasm+0x1a/0x30 [ 4.152853] [ 4.152900] The buggy address belongs to the object at ffff88810430c180 [ 4.152900] which belongs to the cache kmalloc-96 of size 96 [ 4.153226] The buggy address is located 20 bytes inside of [ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0) [ 4.153549] [ 4.153596] The buggy address belongs to the physical page: [ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c [ 4.154000] flags: 0x ---truncated---

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

netfilter: nfconntrackexpect: use expect->helper

Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfcthelp() without holding a reference to the master conntrack is unsafe.

Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nfconntrackexpect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.

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

dmaengine: idxd: fix possible wrong descriptor completion in llistabortdesc()

At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks.

Fix this by completing d instead of found in the final listforeachentrysafe() loop.

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

net: ti: icssg-prueth: fix use-after-free of CPPI descriptor in RX path

cppi5hdescgetpsdata() returns a pointer into the CPPI descriptor. In both emacrxpacket() and emacrxpacketzc(), the descriptor is freed via k3cppidescpoolfree() before the psdata pointer is used by emacrxtimestamp(), which dereferences psdata[0] and psdata[1]. This constitutes a use-after-free on every received packet that goes through the timestamp path.

Defer the descriptor free until after all accesses through the psdata pointer are complete. For emacrxpacket(), move the free into the requeue label so both early-exit and success paths free the descriptor after all accesses are done. For emacrxpacketzc(), move the free to the end of the loop body after emacdispatchskbzc() (which calls emacrxtimestamp()) has returned.

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

ksmbd: replace hardcoded hdr2len with offsetof() in smb2calcmaxoutbuflen()

After this commit (e2b76ab8b5c9 "ksmbd: add support for read compound"), response buffer management was changed to use dynamic iov array. In the new design, smb2calcmaxoutbuflen() expects the second argument (hdr2len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value.

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.

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:

rxrpc: Fix integer overflow in rxgkverifyresponse()

In rxgkverifyresponse(), there's a potential integer overflow due to rounding up tokenlen before checking it, thereby allowing the length check to be bypassed.

Fix this by checking the unrounded value against len too (len is limited as the response must fit in a single UDP packet).

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

seg6: separate dstcache for input and output paths in seg6 lwtunnel

The seg6 lwtunnel uses a single dstcache per encap route, shared between seg6inputcore() and seg6outputcore(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup.

Fix this by splitting the cache into cacheinput and cacheoutput, so each path maintains its own cached dst independently.

batman-adv: hold claim backbone gateways by reference

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

rxrpc: reject undecryptable rxkad response tickets

rxkaddecryptticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether cryptoskcipherdecrypt() succeeded.

A malformed RESPONSE can therefore use a non-block-aligned ticket length, make the decrypt operation fail, and still drive the ticket parser with attacker-controlled bytes.

Check the decrypt result and abort the connection with RXKADBADTICKET when ticket decryption fails.

batman-adv: reject oversized global TT response buffers

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:

net/x25: Fix potential double free of skb

When allocskb fails in x25queuerxframe it calls kfreeskb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain:

x25queuerxframe returns 1 | v x25state3machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25processrxframe returns queued=0 | v x25backlogrcv at line 452 sees queued=0 and calls kfreeskb(skb) again

This would free the same skb twice. Looking at x25backlogrcv:

net/x25/x25in.c:x25backlogrcv() { ... queued = x25processrxframe(sk, skb); ... if (!queued) kfreeskb(skb); }

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

ipv6: icmp: clear skb2->cb[] in ip6errgenicmpv6unreach()

Sashiko AI-review observed:

In ip6errgenicmpv6unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inetskbparm. When skb is cloned into skb2 and passed to icmp6send(), it uses IP6CB(skb2).

IP6CB interprets the IPv4 inetskbparm as an inet6skbparm. The cipso offset in inetskbparm.opt directly overlaps with dsthao in inet6skbparm at offset 18.

If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6send(), mip6addrswap() is called and uses ipv6findtlv(skb, opt->dsthao, IPV6TLVHAO).

This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6destopthao.

Could mip6addrswap() then perform a 16-byte swap that extends past the end of the packet data into skbsharedinfo?

Should the cb array also be cleared in ip6errgenicmpv6unreach() and ip6ip6err() to prevent this?

This patch implements the first suggestion.

I am not sure if ip6ip6err() needs to be changed. A separate patch would be better anyway.

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

net: ti: icssg-prueth: fix missing data copy and wrong recycle in ZC RX dispatch

emacdispatchskbzc() allocates a new skb via napiallocskb() but never copies the packet data from the XDP buffer into it. The skb is passed up the stack containing uninitialized heap memory instead of the actual received packet, leaking kernel heap contents to userspace.

Copy the received packet data from the XDP buffer into the skb using skbcopytolineardata().

Additionally, remove the skbmarkforrecycle() call since the skb is backed by the NAPI page frag allocator, not pagepool. Marking a non-pagepool skb for recycle causes the free path to return pages to a pagepool that does not own them, corrupting pagepool state.

The non-ZC path (emacrxpacket) does not have these issues because it uses napibuildskb() to wrap the existing pagepool page directly, requiring no copy, and correctly marks for recycle since the page comes from pagepooldevallocpages().

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

ip6tunnel: clear skb2->cb[] in ip4ip6err()

Oskar Kjos reported the following problem.

ip4ip6err() calls icmpsend() on a cloned skb whose cb[] was written by the IPv6 receive path as struct inet6skbparm. icmpsend() passes IPCB(skb2) to ipoptionsecho(), which interprets that cb[] region as struct inetskbparm (IPv4). The layouts differ: inet6skbparm.nhoff at offset 14 overlaps inetskbparm.opt.rr, producing a non-zero rr value. ipoptionsecho() then reads optlen from attacker-controlled packet data at sptr[rr+1] and copies that many bytes into dopt->data, a fixed 40-byte stack buffer (IPOPTIONSDATAFIXEDSIZE).

To fix this we clear skb2->cb[], as suggested by Oskar Kjos.

Also add minimal IPv4 header validation (version == 4, ihl >= 5).

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

net/ipv6: ioam6: prevent schema length wraparound in trace fill

ioam6filltracedata() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. ioam6filltracedata() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer.

Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.

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

netfilter: ip6teui64: reject invalid MAC header for all packets

eui64mt6() derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address.

The existing guard only rejects an invalid MAC header when par->fragoff != 0. For packets with par->fragoff == 0, eui64mt6() can still reach ethhdr(skb) even when the MAC header is not valid.

Fix this by removing the par->fragoff != 0 condition so that packets with an invalid MAC header are rejected before accessing ethhdr(skb).

Bluetooth: L2CAP: Fix accepting multiple L2CAPECREDCONNREQ

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

rxrpc: fix RESPONSE authenticator parser OOB read

rxgkverifyauthenticator() copies authlen bytes into a temporary buffer and then passes p + authlen as the parser limit to rxgkdoverifyauthenticator(). Since p is a be32 , that inflates the parser end pointer by a factor of four and lets malformed RESPONSE authenticators read past the kmalloc() buffer.

Decoded from the original latest-net reproduction logs with scripts/decodestacktrace.sh:

BUG: KASAN: slab-out-of-bounds in rxgkverifyresponse() Call Trace: dumpstacklvl() [lib/dumpstack.c:123] printreport() [mm/kasan/report.c:379 mm/kasan/report.c:482] kasanreport() [mm/kasan/report.c:597] rxgkverifyresponse() [net/rxrpc/rxgk.c:1103 net/rxrpc/rxgk.c:1167 net/rxrpc/rxgk.c:1274] rxrpcprocessconnection() [net/rxrpc/connevent.c:266 net/rxrpc/connevent.c:364 net/rxrpc/connevent.c:386] processonework() [kernel/workqueue.c:3281] workerthread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] retfromfork() [arch/x86/kernel/process.c:164]

Allocated by task 54: rxgkverifyresponse() [include/linux/slab.h:954 net/rxrpc/rxgk.c:1155 net/rxrpc/rxgk.c:1274] rxrpcprocessconnection() [net/rxrpc/connevent.c:266 net/rxrpc/connevent.c:364 net/rxrpc/connevent.c:386]

Convert the byte count to be32 units before constructing the parser limit.

bridge: brndsend: linearize skb before parsing ND options

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

net: ioam6: fix OOB and missing lock

When trace->type.bit6 is set:

if (trace->type.bit6) { ... queue = skbgettxqueue(dev, skb); qdisc = rcudereference(queue->qdisc);

This code can lead to an out-of-bounds access of the dev->tx[] array when isinput is true. In such a case, the packet is on the RX path and skb->queuemapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skbgetqueuemapping(skb) will exceed dev->numtxqueues. Add a check to avoid this situation since skbgettxqueue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature.

While at it, add missing lock around qdiscqstatsqlenbacklog(). The function ioam6filltracedata() is called from both softirq and process contexts, hence the use of spinlockbh() here.

bpf: Fix stack-out-of-bounds write in devmap

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

KVM: arm64: Fix ID register initialization for non-protected pKVM guests

In protected mode, the hypervisor maintains a separate instance of the kvm structure for each VM. For non-protected VMs, this structure is initialized from the host's kvm state.

Currently, pkvminitfeaturesfromhost() copies the KVMARCHFLAGIDREGSINITIALIZED flag from the host without the underlying idregs data being initialized. This results in the hypervisor seeing the flag as set while the ID registers remain zeroed.

Consequently, kvmhasfeat() checks at EL2 fail (return 0) for non-protected VMs. This breaks logic that relies on feature detection, such as ctxthastcrx() for TCR2EL1 support. As a result, certain system registers (e.g., TCR2EL1, PIREL1, POREL1) are not saved/restored during the world switch, which could lead to state corruption.

Fix this by explicitly copying the ID registers from the host kvm to the hypervisor kvm for non-protected VMs during initialization, since we trust the host with its non-protected guests' features. Also ensure KVMARCHFLAGIDREGSINITIALIZED is cleared initially in pkvminitfeaturesfromhost so that vmcopyidregs can properly initialize them and set the flag once done.

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

ksmbd: fix OOB write in QUERYINFO for compound requests

When a compound request such as READ + QUERYINFO(Security) is received, and the first command (READ) consumes most of the response buffer, ksmbd could write beyond the allocated buffer while building a security descriptor.

The root cause was that smb2getinfosec() checked buffer space using ppntsdsize from xattr, while buildsecdesc() often synthesized a significantly larger descriptor from POSIX ACLs.

This patch introduces smbaclsecdescscratchlen() to accurately compute the final descriptor size beforehand, performs proper buffer checking with smb2calcmaxoutbuflen(), and uses exact-sized allocation + iov pinning.

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

netfs: Fix read abandonment during retry

Under certain circumstances, all the remaining subrequests from a read request will get abandoned during retry. The abandonment process expects the 'subreq' variable to be set to the place to start abandonment from, but it doesn't always have a useful value (it will be uninitialised on the first pass through the loop and it may point to a deleted subrequest on later passes).

Fix the first jump to "abandon:" to set subreq to the start of the first subrequest expected to need retry (which, in this abandonment case, turned out unexpectedly to no longer have NEEDRETRY set).

Also clear the subreq pointer after discarding superfluous retryable subrequests to cause an oops if we do try to access it.

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

LoongArch: KVM: Make kvmgetvcpubycpuid() more robust

kvmgetvcpubycpuid() takes a cpuid parameter whose type is int, so cpuid can be negative. Let kvmgetvcpubycpuid() return NULL for this case so as to make it more robust.

This fix an out-of-bounds access to kvmarch::phyidmap::physmap[].

can: gw: fix OOB heap access in cgwcsumcrc8rel()