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

USB: serial: ioti: fix heap overflow in getmanufinfo()

getmanufinfo() reads le16tocpu(romdesc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmallocobj(), which is sizeof(struct edgetimanufdescriptor) = 10 bytes.

The Size field comes from the device and is only validated (in checki2cimage()) to make sure the descriptor fits within TIMAXI2CSIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver.

validcsum() is called after readrom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access.

Fix by rejecting descriptors with unexpected length before calling readrom().

[ johan: amend commit message; also check for short descriptors ]

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

KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation

walks1() and kvmwalknesteds2() expect to be called while holding kvm->srcu to guard against memslot changes. While this is generally the case, kvmats12() and kvmfinds1desclevel() call into the respective walkers without taking kvm->srcu.

Fix by acquiring kvm->srcu prior to the table walk in both instances.

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

zram: fix use-after-free in zrambvecwritepartial()

zramreadpage() picks the sync or async backing device read path based on whether the parent bio is NULL. zrambvecwritepartial() passes its parent bio down, so for ZRAMWB slots the read is dispatched asynchronously and zramreadpage() returns 0 while the bio is still in flight. The caller then runs memcpyfrombvec(), zramwritepage() and freepage() on the buffer, leaving the async read to write into a freed page.

zrambvecreadpartial() was switched to NULL in commit 4e3c87b9421d ("zram: fix synchronous reads") for the same reason; the writepartial counterpart was missed.

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

xfrm: policy: fix use-after-free on inexact bin in xfrmpolicybyselctx()

Fix the race by pruning the bin while still holding xfrmpolicylock, before dropping it. Use xfrmpolicyinexactprunebin() directly since the lock is already held. The wrapper xfrmpolicyinexactprunebin() becomes unused and is removed.

Race:

CPU0 (XFRMMSGDELPOLICY) CPU1 (XFRMMSGNEWSPDINFO) ========================== ========================== xfrmpolicybyselctx(): spinlockbh(xfrmpolicylock) bin = xfrmpolicyinexactlookup() xfrmpolicyunlink(pol) spinunlockbh(xfrmpolicylock) xfrmpolicykill(ret) // wide window, lock not held xfrmhashrebuild(): spinlockbh(xfrmpolicylock) xfrmpolicyinexactflush(): kfreercu(bin) // bin freed spinunlockbh(xfrmpolicylock) xfrmpolicyinexactprunebin(bin) // UAF: bin is freed

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

ipv6: mcast: Fix use-after-free when processing MLD queries

When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskbmaypull() calls, leading to a use-after-free [1].

Fix by copying the multicast group address when the packet is initially parsed.

[1] BUG: KASAN: slab-use-after-free in mldquerywork (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118

Workqueue: mld mldquerywork Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:94 lib/dumpstack.c:120) printaddressdescription.constprop.0 (mm/kasan/report.c:378) printreport (mm/kasan/report.c:482) kasanreport (mm/kasan/report.c:595) mldquerywork (net/ipv6/mcast.c:1512) mldquerywork (net/ipv6/mcast.c:1563) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245) </TASK>

[...]

Freed by task 118: kasansavestack (mm/kasan/common.c:57) kasansavetrack (mm/kasan/common.c:78) kasansavefreeinfo (mm/kasan/generic.c:584) kasanslabfree (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskbexpandhead (net/core/skbuff.c:2335) pskbpulltail (net/core/skbuff.c:2878 (discriminator 4)) mldquerywork (net/ipv6/mcast.c:1495 (discriminator 1)) mldquerywork (net/ipv6/mcast.c:1563) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245)

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

ipv4: restrict IPOPTSSRR and IPOPTLSRR options

This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAPNETRAW capability.

This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information.

While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths.

RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.

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

netfilter: conntrackirc: fix possible out-of-bounds read

When parsing fails after we've matched the command string we should bail out instead of trying to match a different command.

This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.

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

netfilter: nftexthdr: fix register tracking for FPRESENT flag

nftexthdrinit() passes user-controlled priv->len to nftparseregisterstore(), which marks that many bytes in the register bitmap as initialized. However, when NFTEXTHDRFPRESENT is set, the eval paths write only 1 byte (nftregstore8) or 4 bytes (dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nftregs.

Bail out if userspace requests too much data when FPRESENT is set.

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

net: guard timestamp cmsgs to real error queue skbs

skbiserrqueue() treats PACKETOUTGOING as the sole marker for an skb from skerrorqueue. That assumption is not true for AFPACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkttype == PACKETOUTGOING, but their skb->cb is owned by AFPACKET instead of struct sockexterrskb.

If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AFPACKET control-buffer state as sockexterrskb::optstats. With SORXQOVFL enabled, the packet drop counter overlaps optstats. An odd drop count makes the path emit SCMTIMESTAMPINGOPTSTATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents.

Keep skbiserrqueue() local to net/socket.c, but make it verify that the PACKETOUTGOING marker is paired with the sockrmemfree destructor installed by sockqueueerrskb(). AFPACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate skerrorqueue entries keep the PACKETOUTGOING marker and sockrmemfree ownership.

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

tcp: restrict SOATTACHFILTER to priv users

This patch restricts the use of SOATTACHFILTER (cBPF) on TCP sockets to users with CAPNETADMIN capability.

This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.

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

netfilter: nflog: validate MAC header was set before dumping it

The fallback path of dumpmacheader() guards the MAC header access only with "skb->macheader != skb->networkheader", without checking skbmacheaderwasset(). When the MAC header is unset, macheader is 0xffff, so the test passes and skbmacheader(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hardheaderlen bytes out of bounds into the kernel log.

This is reachable via the netdev logger: nflogunknownpacket() calls dumpmacheader() unconditionally, and an skb sent through AFPACKET with PACKETQDISCBYPASS reaches the egress hook with macheader still unset (devqueuexmit(), which would reset it, is bypassed).

Add the skbmacheaderwasset() check the ARPHRDETHER path already uses, and replace the open-coded MAC header length test with skbmacheaderlen(). Only skbs with an unset MAC header are affected; valid ones are dumped as before.

BUG: KASAN: slab-out-of-bounds in dumpmacheader (net/netfilter/nflogsyslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasanreport (mm/kasan/report.c:595) dumpmacheader (net/netfilter/nflogsyslog.c:831) nflognetdevpacket (net/netfilter/nflogsyslog.c:938 net/netfilter/nflogsyslog.c:963) nflogpacket (net/netfilter/nflog.c:260) nftlogeval (net/netfilter/nftlog.c:60) nftdochain (net/netfilter/nftablescore.c:285) nftdochainnetdev (net/netfilter/nftchainfilter.c:307) nfhookslow (net/netfilter/core.c:619) nfhookdirectegress (net/packet/afpacket.c:257) packetxmit (net/packet/afpacket.c:280) packetsendmsg (net/packet/afpacket.c:3114) syssendto (net/socket.c:2265)

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

net: skbuff: fix missing zerocopy reference in pskbcarve helpers

pskbcarveinsideheader() and pskbcarveinsidenonlinear() both copy the old skbsharedinfo header into a new buffer via memcpy(), which includes the destructorarg pointer (uarg) for MSGZEROCOPY skbs. Neither function calls netzcopyget() for the new shinfo, creating an unaccounted holder: every skbsharedinfo with destructorarg set will call skbzcopyclear() once when freed, but the corresponding netzcopyget() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubufinfomsgzc while TX skbs still hold live destructorarg pointers.

KASAN reports use-after-free on a freed ubufinfomsgzc:

BUG: KASAN: slab-use-after-free in skbreleasedata+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220

Call Trace: skbreleasedata+0x77b/0x810 kfreeskblistreason+0x13e/0x610 skbreleasedata+0x4cd/0x810 skskbreasondrop+0xf3/0x340 skbqueuepurgereason+0x282/0x440 rdstcpincfree+0x1e/0x30 rdsrecvmsg+0x354/0x1780 sysrecvmsg+0xdf/0x180

Allocated by task 219: msgzerocopyrealloc+0x157/0x7b0 tcpsendmsglocked+0x2892/0x3ba0

Freed by task 219: iprecverror+0x74a/0xb10 tcprecvmsg+0x475/0x530

The skb consuming the late access still referenced the same uarg via shinfo->destructorarg copied by pskbcarveinsidenonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration.

The fix follows the pattern of pskbexpandhead() which has the same memcpy/cloned structure. For pskbcarveinsideheader(), netzcopyget() is placed after skborphanfrags() succeeds, so the orphan error path needs no cleanup. For pskbcarveinsidenonlinear(), netzcopyget() is placed after all failure points and just before skbreleasedata(), so no error path needs cleanup at all -- matching pskbexpandhead() more closely and avoiding the need for a balancing netzcopyput().

Bluetooth: fix UAF in btacceptdequeue()

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

ipc: limit nextid allocation to the valid ID range

The checkpoint/restore sysctl path can request the next SysV IPC id through ids->nextid. ipcidralloc() currently forwards that request to idralloc() with an open-ended upper bound.

If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipcmni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object.

The bug is in ipcidralloc() in the checkpoint/restore path.

1. ids->nextid is passed to:

idralloc(&ids->ipcsidr, new, ipcidtoidx(nextid), 0, ...)

2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idralloc() can spill past ipcmni and allocate an entry beyond the valid IPC id range.

3. The new object id is still encoded with the narrower SysV IPC index width:

new->id = (new->seq << ipcmniseqshift()) + idx

4. Later removal goes through ipcrmid(), which uses:

ipcidtoidx(ipcp->id)

That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index.

5. For shared memory, shmdestroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer.

6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory.

Prevent this by bounding the requested allocation to ipcmni so the checkpoint/restore path fails once the valid range is exhausted.

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

net/sched: actapi: use RCU with deferred freeing for action lifecycle

When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action.

Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER:

0: mutexlock() <-- holds the idr lock 0: rcureadlock() 0: p = idrfind(idr, index) <-- action p is valid (RCU protects IDR) 0: mutexunlock() <-- releases the idr lock 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) <-- Action removed from IDR 1: mutexunlock() <-- mutex released allowing us to delete the action 1: tcfactioncleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcountincnotzero(&p->tcfarefcnt) <-- ouch, UAF p points to freed memory

This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcuhead to tcaction used in the deferral and introducing a callrcu() in the delete path to defer the final kfree().

Note: this is a revert of commit d7fb60b9cafb ("netsched: get rid of tcfarcu") but also modernization/simplification to directly use kfreercu().

Let's illustrate the new restored code path:

0: rcureadlock() 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) 1: mutexunlock() 1: callrcu(&p->tcfarcu, tcfactionrcufree) <-- defer kfree after grace period 0: p = idrfind(idr, index) 0: refcountincnotzero(&p->tcfarefcnt) <-- fails, refcnt already 0 1: rcureadunlock() <-- release so freeing can run after grace period

After CPU1 calls idrremove(), the object is no longer reachable through the IDR. CPU0's subsequent idrfind() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.

ALSA: PCM: Fix wait queue list corruption in sndpcmdrain() on linked streams

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

mm/listlru: drain before clearing xarray entry on reparent

memcgreparentlistlrus() clears the dying memcg's xarray entry with xasstore(&xas, NULL) before reparenting its per-node lists into the parent. This opens a window where a concurrent listlrudel() arriving for the dying memcg sees xaload() == NULL, walks to the parent in locklistlruofmemcg(), takes the parent's per-node lock, and calls listdelinit() on an item still physically linked on the dying memcg's list.

If another in-flight thread holds the dying memcg's per-node lock at the same moment (another listlrudel, or a listlruwalkone running an isolate callback), both threads modify ->next/->prev pointers on the same physical list under different locks. Adjacent items can corrupt each other's links.

Fix it by reversing the order: reparent each per-node list and mark the child's list lru dead and then clear the xarray entry. Any concurrent listlru op that finds the still-set xarray entry either takes the dying memcg's per-node lock (synchronizing with the drain) or sees LONGMIN and walks to the parent, where the items now live.

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

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

mm/hugememory: update file PMD counter before folioput()

splithugepmdlocked() updates the file/shmem RSS counter after dropping the PMD mapping's folio reference. If folioput() drops the last reference, mmcounterfile() can later read freed folio state via foliotestswapbacked().

Move the counter update before folioput().

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

accel/ivpu: Fix signed integer truncation in IPC receive

Fix potential buffer overflow where firmware-supplied datasize is cast to signed int before being used in mint(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer.

Change mint(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.

drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11

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

drm/amd/display: Clamp VBIOS HDMI retimer register count to array size

[Why & How] The VBIOS integrated info tables (v111 and v21) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dpexthdmiregsettings[9] and dpexthdmi6gregsettings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe.

Clamp each register count to the destination array size using mint() before the copy loops, in both getintegratedinfov11() and getintegratedinfov21().

(cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)

drm/i915/gem: Fix phys BO pread/pwrite with offset

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

ASoC: codecs: simple-mux: Fix enum control bounds check

simplemuxcontrolput() rejects values greater than e->items, but enum control values are zero based. For the two-entry mux used by this driver, valid values are 0 and 1, so value 2 must be rejected as well.

Accepting e->items can store an invalid mux state, pass it to the GPIO setter, and pass it on to the DAPM mux update path where it is used as an index into the enum text array.

Use the same >= e->items check used by the ASoC enum helpers.

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

mm/damon/sysfs-schemes: delete tried region in regionsrmdirs()

DAMON sysfs maintains the DAMOS tried region directory objects via a linked list. When the user requests refresh of the directories, DAMON sysfs removes all the region directories first, and then generate updated regions directory on the empty space. The removal function (damonsysfsschemeregionsrmdirs()) only puts the kobj objects. Deletion of the container region object from the linked list is done inside the kobj release callback function.

If somehow the callback invocation is delayed, the list will contain regions list that gonna be freed. If the updated region directories creation is started in this situation, the list can be corrupted and use-after-free can happen.

Because the kobj objects are managed by only DAMON sysfs, the issue cannot happen in normal situation. But, such delays can be made on kernels that built with CONFIGDEBUGKOBJECTRELEASE. On the kernel, the issue can indeed be reproduced like below.

# damo start --damosaction stat # cd /sys/kernel/mm/damon/admin/kdamonds/0/ # for i in {1..10}; do echo updateschemestriedregions > state; done # dmesg | grep underflow [ 89.296152] refcountt: underflow; use-after-free.

Fix the issue by removing the region object from the list when decrementing the reference count.

Also update damossysfspopulateregiondir() to add the region object to the list only after the kobjectinitandadd() is success, so that fail of kobjectinitandadd() is not leaving the deallocated object on the list.

The issue was discovered [1] by Sashiko.

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

usb: gadget: net2280: Fix double free in probe error path

usbinitializegadget() installs gadgetrelease() as the release callback for the embedded gadget device. The struct net2280 instance is therefore released through gadgetrelease() when the gadget device's last reference is dropped.

The probe error path calls net2280remove(), which tears down the partially initialized device and drops the gadget reference with usbputgadget(). Calling kfree(dev) afterwards can free the same object again.

Drop the explicit kfree() and let the gadget device release callback handle the final free. This issue was found by a static analysis tool I am developing.

A flaw in the Linux kernel's ebtables SNAT target allows writing to shared memory pages when rewriting ARP sender hardware addresses without ensuring writability, potentially causing file/memory corruption or denial of service.

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

x86/ftrace: Relocate %rip-relative percpu refs in dynamic trampolines

With CONFIGCALLDEPTHTRACKING enabled on an x86 retbleed-affected platform (eg: Skylake), with retbleed=stuff, registering a dynamic ftrace trampoline crashes on the first call into the traced function:

BUG: unable to handle page fault for address: ffff88817ae18880 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 4b53067 P4D 4b53067 PUD 0 Oops: Oops: 0002 [#1] SMP PTI CPU: 3 UID: 0 PID: 187 Comm: usleep Not tainted 7.0.10 #243 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Code: 24 78 00 00 00 00 48 89 ea 48 89 54 24 20 48 8b b4 24 b8 00 00 00 48 8b bc 24 b0 00 00 00 48 89 bc 24 80 00 00 00 48 83 ef 05 <65> 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89 Call Trace: <TASK> ? findheldlock ? excpagefault ? lockrelease ? x64sysclocknanosleep ? lockdephardirqsonprepare ? tracehardirqson x64sysclocknanosleep dosyscall64 ? excpagefault ? calldepthreturnthunk entrySYSCALL64afterhwframe ... Kernel panic - not syncing: Fatal exception

This small reproducer allows to easily trigger the crash:

# echo 'p x64sysclocknanosleep' > /sys/kernel/tracing/kprobeevents # echo 1 > /sys/kernel/tracing/events/kprobes/px64sysclocknanosleep0/enable # usleep 1

Monitoring the crash under GDB points to the exact instruction in charge of incrementing the call depth:

sarq $5, %gs:x86calldepth(%rip)

This instruction matches the one inserted by the ftraceregscaller from ftrace64.S. This emitted code was likely working fine until the introduction of

59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PERCPUVAR()"):

it has made the call depth accounting addressing relative to $rip, instead of being based on an absolute address.

As this code exact location depends on where the trampoline lives in memory, the corresponding displacement needs to be adjusted at runtime to actually correctly find the per-cpu x86calldepth value, otherwise the targeted address is wrong, leading to the page fault seen above.

Fix the %rip-relative displacement of the copied CALLDEPTHACCOUNT instruction (from ftraceregscaller) by calling textpokeapplyrelocation(), as it is done for example by the x86 BPF JIT compiler through x86calldepthemitaccounting(). This corrects both CALLDEPTHACCOUNT slots, in ftracecaller and ftraceregscaller.

[ bp: Massage. ]

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

Input: elani2c - validate firmware size before use

Ensure that the firmware file is large enough to contain the expected number of pages and the signature (which resides at the end of the firmware blob) before accessing them to prevent potential out-of-bounds reads.

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

KVM: SEV: Require in-GHCB scratch area if GHCB v2+ is in use

As per the GHCB spec, when using GHCB v2+ require the software scratch area to reside in the GHCB's shared buffer. Note, things like Page State Change (PSC) requests rely on this behavior, as the guest can't provide a length when making the request, i.e. the size of the guest payload is bounded by the size of the shared buffer.

Failure to force usage of the GHCB, and a slew of other flaws, lets a malicious SNP guest corrupt host kernel heap memory, and leak host heap layout information.

setupvmgexitscratch() allocates a buffer via kvzalloc(exitinfo2), where exitinfo2 is guest-controlled. With exitinfo2=24, this yields a 24-byte allocation in kmalloc-cg-32 (32-byte slab objects). The buffer holds an 8-byte pschdr followed by 8-byte pscentry structs, so only entries[0] and entries[1] are in-bounds.

snpbeginpsc() validates endentry against VMGEXITPSCMAXCOUNT (253) but NOT against the actual buffer size:

idxend = hdr->endentry;

if (idxend >= VMGEXITPSCMAXCOUNT) { // checks 253, not buffer snpcompletepsc(svm, ...); return 1; }

for (idx = idxstart; idx <= idxend; idx++) { entrystart = entries[idx]; // OOB when idx >= 2

The guest sets endentry=10+, causing the host to iterate entries[2+] which are OOB into adjacent slab objects. For each OOB entry:

- The host reads 8 bytes (OOB READ / info leak oracle) - If the data passes PSC validation, snpcompleteonepsc() writes curpage = 1 or 512 into the entry (OOB WRITE, sev.c:3806) - If validation fails, the error response reveals whether adjacent memory is zero vs non-zero (information disclosure to guest)

The guest controls allocation size (exitinfo2), entry range (curentry/endentry), and can fire unlimited VMGEXITs to repeatedly hit different slab positions.

By exploiting the variety of bugs, a malicious SEV-SNP guest can: - OOB read adjacent kmalloc-cg-32 objects (heap layout disclosure) - OOB write curpage bits into adjacent objects (heap corruption) - Trigger use-after-free conditions across VMGEXITs

E.g. with KASAN enabled, a single insmod of the PoC guest module produces 73 KASAN reports:

BUG: KASAN: slab-out-of-bounds in snpbeginpsc+0x126/0x890 Read of size 8 at addr ffff888219ffb5e0 by task qemu-system-x86/2199

BUG: KASAN: slab-out-of-bounds in snpbeginpsc+0x468/0x890 Write of size 8 at addr ffff888351566648 by task qemu-system-x86/2199

The buggy address belongs to the object at ffff888XXXXXXXXX which belongs to the cache kmalloc-cg-32 of size 32 The buggy address is located N bytes to the right of allocated 32-byte region [ffff888XXXXXXXXX, ffff888XXXXXXXXX)

Breakdown: 62 slab-out-of-bounds (reads + writes past allocation) 7 slab-use-after-free 4 use-after-free

All credit to Stan for the wonderful description and reproducer!

[sean: write changelog]