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:
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/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.
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:
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()
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Fix the descriptor address in kvmatswapdesc()
Using "(u64 user )hva + offset" to get the virtual addresses of S1/S2 descriptors looks really wrong, if offset is not zero. What we want to get for swapping is hva + offset, not hva + offset8. ;-)
Fix it.
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: validate bsscfg indices in IF events
brcmffwehhandleifevent() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check.
Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array.
[add missing wifi prefix]
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hcisync: Fix UAF in lereadfeaturescomplete
This fixes the following backtrace caused by hciconn being freed before lereadfeaturescomplete but after hcilereadremotefeaturessync so hciconndel -> hcicmdsyncdequeue is not able to prevent it:
================================================================== BUG: KASAN: slab-use-after-free in instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] BUG: KASAN: slab-use-after-free in atomicdecandtest include/linux/atomic/atomic-instrumented.h:1383 [inline] BUG: KASAN: slab-use-after-free in hciconndrop include/net/bluetooth/hcicore.h:1688 [inline] BUG: KASAN: slab-use-after-free in lereadfeaturescomplete+0x5b/0x340 net/bluetooth/hcisync.c:7344 Write of size 4 at addr ffff8880796b0010 by task kworker/u9:0/52
CPU: 0 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcd/0x630 mm/kasan/report.c:482 kasanreport+0xe0/0x110 mm/kasan/report.c:595 checkregioninline mm/kasan/generic.c:194 [inline] kasancheckrange+0x100/0x1b0 mm/kasan/generic.c:200 instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] atomicdecandtest include/linux/atomic/atomic-instrumented.h:1383 [inline] hciconndrop include/net/bluetooth/hcicore.h:1688 [inline] lereadfeaturescomplete+0x5b/0x340 net/bluetooth/hcisync.c:7344 hcicmdsyncwork+0x1ff/0x430 net/bluetooth/hcisync.c:334 processonework+0x9ba/0x1b20 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3421 kthread+0x3c5/0x780 kernel/kthread.c:463 retfromfork+0x983/0xb10 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246 </TASK>
Allocated by task 5932: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 poisonkmallocredzone mm/kasan/common.c:400 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:417 kmallocnoprof include/linux/slab.h:957 [inline] kzallocnoprof include/linux/slab.h:1094 [inline] hciconnadd+0xf8/0x1c70 net/bluetooth/hciconn.c:963 hciconnaddunset+0x76/0x100 net/bluetooth/hciconn.c:1084 leconncompleteevt+0x639/0x1f20 net/bluetooth/hcievent.c:5714 hcileenhconncompleteevt+0x23d/0x380 net/bluetooth/hcievent.c:5861 hcilemetaevt+0x357/0x5e0 net/bluetooth/hcievent.c:7408 hcieventfunc net/bluetooth/hcievent.c:7716 [inline] hcieventpacket+0x685/0x11c0 net/bluetooth/hcievent.c:7773 hcirxwork+0x2c9/0xeb0 net/bluetooth/hcicore.c:4076 processonework+0x9ba/0x1b20 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3421 kthread+0x3c5/0x780 kernel/kthread.c:463 retfromfork+0x983/0xb10 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246
Freed by task 5932: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 kasansavefreeinfo+0x3b/0x60 mm/kasan/generic.c:587 kasansavefreeinfo mm/kasan/kasan.h:406 [inline] poisonslabobject mm/kasan/common.c:252 [inline] kasanslabfree+0x5f/0x80 mm/kasan/common.c:284 kasanslabfree include/linux/kasan.h:234 [inline] slabfreehook mm/slub.c:2540 [inline] slabfree mm/slub.c:6663 [inline] kfree+0x2f8/0x6e0 mm/slub.c:6871 devicerelease+0xa4/0x240 drivers/base/core.c:2565 kobjectcleanup lib/kobject.c:689 [inline] kobjectrelease lib/kobject.c:720 [inline] krefput include/linux/kref.h:65 [inline] kobjectput+0x1e7/0x590 lib/kobject. ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE
When installing an emulated MMIO SPTE, do so after dropping/zapping the existing SPTE (if it's shadow-present). While commit a54aa15c6bda3 was right about it being impossible to convert a shadow-present SPTE to an MMIO SPTE due to a guest write, it failed to account for writes to guest memory that are outside the scope of KVM.
E.g. if host userspace modifies a shadowed gPTE to switch from a memslot to emulted MMIO and then the guest hits a relevant page fault, KVM will install the MMIO SPTE without first zapping the shadow-present SPTE.
------------[ cut here ]------------ isshadowpresentpte(sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at markmmiospte+0xb2/0xc0 [kvm], CPU#0: vmxeptstaler/4292 Modules linked in: kvmintel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmxeptstaler Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:markmmiospte+0xb2/0xc0 [kvm] Call Trace: <TASK> mmusetspte+0x237/0x440 [kvm] eptpagefault+0x535/0x7f0 [kvm] kvmmmudopagefault+0xee/0x1f0 [kvm] kvmmmupagefault+0x8d/0x620 [kvm] vmxhandleexit+0x18c/0x5a0 [kvmintel] kvmarchvcpuioctlrun+0xc55/0x1c20 [kvm] kvmvcpuioctl+0x2d5/0x980 [kvm] x64sysioctl+0x8a/0xd0 dosyscall64+0xb5/0x730 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x47fa3f </TASK> ---[ end trace 0000000000000000 ]---
In the Linux kernel, the following vulnerability has been resolved:
xen/privcmd: restrict usage in unprivileged domU
The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains.
In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature.
The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest.
Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today.
The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot.
This is XSA-482
--- V2: - defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich) - wait in open() if target domain isn't known yet - issue message in case no target domain found (Jan Beulich)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: do not expire session on binding failure
When a multichannel session binding request fails (e.g. wrong password), the error path unconditionally sets sess->state = SMB2SESSIONEXPIRED. However, during binding, sess points to the target session looked up via ksmbdsessionlookupslowpath() -- which belongs to another connection's user. This allows a remote attacker to invalidate any active session by simply sending a binding request with a wrong password (DoS).
Fix this by skipping session expiration when the failed request was a binding attempt, since the session does not belong to the current connection. The reference taken by ksmbdsessionlookupslowpath() is still correctly released via ksmbdusersessionput().
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix buffer overread in rxgkdoverifyauthenticator()
Fix rxgkdoverifyauthenticator() to check the buffer size before checking the nonce.
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:
xdp: produce a warning when calculated tailroom is negative
Many ethernet drivers report xdp Rx queue frag size as being the same as DMA write size. However, the only user of this field, namely bpfxdpfragsincreasetail(), clearly expects a truesize.
Such difference leads to unspecific memory corruption issues under certain circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when running xskxceiver's XDPADJUSTTAILGROWMULTIBUFF, 6K packet fully uses all DMA-writable space in 2 buffers. This would be fine, if only rxq->fragsize was properly set to 4K, but value of 3K results in a negative tailroom, because there is a non-zero page offset.
We are supposed to return -EINVAL and be done with it in such case, but due to tailroom being stored as an unsigned int, it is reported to be somewhere near UINTMAX, resulting in a tail being grown, even if the requested offset is too much (it is around 2K in the abovementioned test). This later leads to all kinds of unspecific calltraces.
[ 7340.337579] xskxceiver[1440]: segfault at 1da718 ip 00007f4161aeac9d sp 00007f41615a6a00 error 6 [ 7340.338040] xskxceiver[1441]: segfault at 7f410000000b ip 00000000004042b5 sp 00007f415bffecf0 error 4 [ 7340.338179] in libc.so.6[61c9d,7f4161aaf000+160000] [ 7340.339230] in xskxceiver[42b5,400000+69000] [ 7340.340300] likely on CPU 6 (core 0, socket 6) [ 7340.340302] Code: ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 <4c> 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f0 fe ff ff 89 85 ec fe [ 7340.340888] likely on CPU 3 (core 0, socket 3) [ 7340.345088] Code: 00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff <8b> 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7 [ 7340.404334] Oops: general protection fault, probably for non-canonical address 0x6d255010bdffc: 0000 [#1] SMP NOPTI [ 7340.405972] CPU: 7 UID: 0 PID: 1439 Comm: xskxceiver Not tainted 6.19.0-rc1+ #21 PREEMPT(lazy) [ 7340.408006] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 [ 7340.409716] RIP: 0010:lookupswapcgroupid+0x44/0x80 [ 7340.410455] Code: 83 f8 1c 73 39 48 ba ff ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 <8b> 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89 [ 7340.412787] RSP: 0018:ffffcc5c04f7f6d0 EFLAGS: 00010202 [ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010 [ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff [ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0 [ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0 [ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500 [ 7340.418229] FS: 0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000 [ 7340.419489] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7340.420286] CR2: 00007f415bfffd58 CR3: 0000000103f03002 CR4: 0000000000772ef0 [ 7340.421237] PKRU: 55555554 [ 7340.421623] Call Trace: [ 7340.421987] <TASK> [ 7340.422309] ? softleaffrompte+0x77/0xa0 [ 7340.422855] swapptebatch+0xa7/0x290 [ 7340.423363] zapnonpresentptes.constprop.0.isra.0+0xd1/0x270 [ 7340.424102] zappterange+0x281/0x580 [ 7340.424607] zappmdrange.isra.0+0xc9/0x240 [ 7340.425177] unmappagerange+0x24d/0x420 [ 7340.425714] unmapvmas+0xa1/0x180 [ 7340.426185] exitmmap+0xe1/0x3b0 [ 7340.426644] mmput+0x41/0x150 [ 7340.427098] exitmm+0xb1/0x110 [ 7340.427539] doexit+0x1b2/0x460 [ 7340.427992] dogroupexit+0x2d/0xc0 [ 7340.428477] getsignal+0x79d/0x7e0 [ 7340.428957] archdosignalorrestart+0x34/0x100 [ 7340.429571] exittousermodeloop+0x8e/0x4c0 [ 7340.430159] dosyscall64+0x188/ ---truncated---