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.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: Compare MACs in constant time
To prevent timing attacks, MAC comparisons need to be constant-time. Replace the memcmp() with the correct function, cryptomemneq().
bpf: Fix stack-out-of-bounds write in devmap
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:
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:
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:
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:
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:
tipc: fix bcackers underflow on duplicate GRPACKMSG
The GRPACKMSG handler in tipcgroupprotorcv() currently decrements bcackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round.
Because bcackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipcgroupbccong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated.
Fix this by ignoring duplicate or stale ACKs before touching bcacked or bcackers. This makes repeated GRPACKMSG handling idempotent and prevents the underflow path.
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/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:
RDMA/irdma: Harden depth calculation functions
An issue was exposed where OS can pass in U32MAX for SQ/RQ/SRQ size. This can cause integer overflow and truncation of SQ/RQ/SRQ depth returning a success when it should have failed.
Harden the functions to do all depth calculations and boundary checking in u64 sizes.
In the Linux kernel, the following vulnerability has been resolved:
team: fix headerops type confusion with non-Ethernet ports
Similar to commit 950803f72547 ("bonding: fix type confusion in bondsetupbyslave()") team has the same class of headerops type confusion.
For non-Ethernet ports, teamsetupbyport() copies portdev->headerops directly. When the team device later calls devhardheader() or devparseheader(), these callbacks can run with the team netdevice instead of the real lower device, so netdevpriv(dev) is interpreted as the wrong private type and can crash.
The syzbot report shows a crash in bondheadercreate(), but the root cause is in team: the topology is gre -> bond -> team, and team calls the inherited headerops with its own netdevice instead of the lower device, so bondheadercreate() receives a team device and interprets netdevpriv() as bonding private data, causing a type confusion crash.
Fix this by introducing team headerops wrappers for create/parse, selecting a team port under RCU, and calling the lower device callbacks with port->dev, so each callback always sees the correct netdevice context.
Also pass the selected lower device to the lower parse callback, so recursion is bounded in stacked non-Ethernet topologies and parse callbacks always run with the correct device context.
In the Linux kernel, the following vulnerability has been resolved:
futex: Require sysfutexrequeue() to have identical flags
Nicholas reported that his LLM found it was possible to create a UaF when sysfutexrequeue() is used with different flags. The initial motivation for allowing different flags was the variable sized futex, but since that hasn't been merged (yet), simply mandate the flags are identical, as is the case for the old style sysfutex() requeue operations.
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix RxGK token loading to check bounds
rxrpcpreparsexdryfsrxgk() reads the raw key length and ticket length from the XDR token as u32 values and passes each through roundup(x, 4) before using the rounded value for validation and allocation. When the raw length is >= 0xfffffffd, roundup() wraps to 0, so the bounds check and kzalloc both use 0 while the subsequent memcpy still copies the original ~4 GiB value, producing a heap buffer overflow reachable from an unprivileged addkey() call.
Fix this by:
(1) Rejecting raw key lengths above AFSTOKENGKKEYMAX and raw ticket lengths above AFSTOKENGKTOKENMAX before rounding, consistent with the caps that the RxKAD path already enforces via AFSTOKENRKTIXMAX.
(2) Sizing the flexible-array allocation from the validated raw key length via structsizet() instead of the rounded value.
(3) Caching the raw lengths so that the later field assignments and memcpy calls do not re-read from the token, eliminating a class of TOCTOU re-parse.
The control path (valid token with lengths within bounds) is unaffected.
In the Linux kernel, the following vulnerability has been resolved:
xsk: tighten UMEM headroom validation to account for tailroom and min frame
The current headroom validation in xdpumemreg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. Furthermore if multi-buffer would come to play then skbsharedinfo stored at the end of XSK frame would be corrupted.
HW typically works with 128-aligned sizes so let us provide this value as bare minimum.
Multi-buffer setting is known later in the configuration process so besides accounting for 128 bytes, let us also take care of tailroom space upfront.
blktrace: fix thiscpuread/write in preemptible context
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:
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:
rtnetlink: add missing netlinknscapable() check for peer netns
rtnlnewlink() lacks a CAPNETADMIN capability check on the peer network namespace when creating paired devices (veth, vxcan, netkit). This allows an unprivileged user with a user namespace to create interfaces in arbitrary network namespaces, including initnet.
Add a netlinknscapable() check for CAPNETADMIN in the peer namespace before allowing device creation to proceed.
In the Linux kernel, the following vulnerability has been resolved:
xsk: validate MTU against usable frame size on bind
AFXDP bind currently accepts zero-copy pool configurations without verifying that the device MTU fits into the usable frame space provided by the UMEM chunk.
This becomes a problem since we started to respect tailroom which is subtracted from chunksize (among with headroom). 2k chunk size might not provide enough space for standard 1500 MTU, so let us catch such settings at bind time. Furthermore, validate whether underlying HW will be able to satisfy configured MTU wrt XSK's frame size multiplied by supported Rx buffer chain length (that is exposed via netdevice::xdpzcmaxsegs).
bpf: Properly mark live registers for indirect jumps
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:
net: ipv4: fix ARM64 alignment fault in multipath hash seed
struct sysctlfibmultipathhashseed contains two u32 fields (userseed and mpseed), making it an 8-byte structure with a 4-byte alignment requirement.
In fibmultipathhashfromkeys(), the code evaluates the entire struct atomically via READONCE():
mpseed = READONCE(net->ipv4.sysctlfibmultipathhashseed).mpseed;
While this silently works on GCC by falling back to unaligned regular loads which the ARM64 kernel tolerates, it causes a fatal kernel panic when compiled with Clang and LTO enabled.
Commit e35123d83ee3 ("arm64: lto: Strengthen READONCE() to acquire when CONFIGLTO=y") strengthens READONCE() to use Load-Acquire instructions (ldar / ldapr) to prevent compiler reordering bugs under Clang LTO. Since the macro evaluates the full 8-byte struct, Clang emits a 64-bit ldar instruction. ARM64 architecture strictly requires ldar to be naturally aligned, thus executing it on a 4-byte aligned address triggers a strict Alignment Fault (FSC = 0x21).
Fix the read side by moving the READONCE() directly to the u32 member, which emits a safe 32-bit ldar Wn.
Furthermore, Eric Dumazet pointed out that WRITEONCE() on the entire struct in procfibmultipathhashsetseed() is also flawed. Analysis shows that Clang splits this 8-byte write into two separate 32-bit str instructions. While this avoids an alignment fault, it destroys atomicity and exposes a tear-write vulnerability. Fix this by explicitly splitting the write into two 32-bit WRITEONCE() operations.
Finally, add the missing READONCE() when reading userseed in procfibmultipathhashseed() to ensure proper pairing and concurrency safety.
In the Linux kernel, the following vulnerability has been resolved:
xsk: Fix fragment node deletion to prevent buffer leak
After commit b692bf9a7543 ("xsk: Get rid of xdpbuffxsk::xskblistnode"), the listnode field is reused for both the xskb pool list and the buffer free list, this causes a buffer leak as described below.
xpfree() checks if a buffer is already on the free list using listempty(&xskb->listnode). When listdel() is used to remove a node from the xskb pool list, it doesn't reinitialize the node pointers. This means listempty() will return false even after the node has been removed, causing xpfree() to incorrectly skip adding the buffer to the free list.
Fix this by using listdelinit() instead of listdel() in all fragment handling paths, this ensures the list node is reinitialized after removal, allowing the listempty() to work correctly.
icmp: fix NULL pointer dereference in icmptagvalidation()
In the Linux kernel, the following vulnerability has been resolved:
nvmet: move async event work off nvmet-wq
For target nvmetctrlfree() flushes ctrl->asynceventwork. If nvmetctrlfree() runs on nvmet-wq, the flush re-enters workqueue completion for the same worker:-
A. Async event work queued on nvmet-wq (prior to disconnect): nvmetexecuteasyncevent() queuework(nvmetwq, &ctrl->asynceventwork)
nvmetaddasyncevent() queuework(nvmetwq, &ctrl->asynceventwork)
B. Full pre-work chain (RDMA CM path): nvmetrdmacmhandler() nvmetrdmaqueuedisconnect() nvmetrdmaqueuedisconnect() queuework(nvmetwq, &queue->releasework) processonework() lock((wqcompletion)nvmet-wq) <--------- 1st nvmetrdmareleasequeuework()
C. Recursive path (same worker): nvmetrdmareleasequeuework() nvmetrdmafreequeue() nvmetsqdestroy() nvmetctrlput() nvmetctrlfree() flushwork(&ctrl->asynceventwork) flushwork() touchwqlockdepmap() lock((wqcompletion)nvmet-wq) <--------- 2nd
Lockdep splat:
============================================ WARNING: possible recursive locking detected 6.19.0-rc3nvme+ #14 Tainted: G N -------------------------------------------- kworker/u192:42/44933 is trying to acquire lock: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: touchwqlockdepmap+0x26/0x90
but task is already holding lock: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processonework+0x53e/0x660
3 locks held by kworker/u192:42/44933: #0: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processonework+0x53e/0x660 #1: ffffc9000e6cbe28 ((workcompletion)(&queue->releasework)){+.+.}-{0:0}, at: processonework+0x1c5/0x660 #2: ffffffff82d4db60 (rcureadlock){....}-{1:3}, at: flushwork+0x62/0x530
Workqueue: nvmet-wq nvmetrdmareleasequeuework [nvmetrdma] Call Trace: flushwork+0x268/0x530 nvmetctrlfree+0x140/0x310 [nvmet] nvmetcqput+0x74/0x90 [nvmet] nvmetrdmafreequeue+0x23/0xe0 [nvmetrdma] nvmetrdmareleasequeuework+0x19/0x50 [nvmetrdma] processonework+0x206/0x660 workerthread+0x184/0x320 kthread+0x10c/0x240 retfromfork+0x319/0x390
Move async event work to a dedicated nvmet-aen-wq to avoid reentrant flush on nvmet-wq.
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Only put the call ref if one was acquired
rxrpcinputpacketonconn() can process a to-client packet after the current client call on the channel has already been torn down. In that case chan->call is NULL, rxrpctrygetcall() returns NULL and there is no reference to drop.
The client-side implicit-end error path does not account for that and unconditionally calls rxrpcputcall(). This turns a protocol error path into a kernel crash instead of rejecting the packet.
Only drop the call reference if one was actually acquired. Keep the existing protocol error handling unchanged.