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

smb: client: avoid double-free in smbdfreesendio() after smbdsendbatchflush()

smbdsendbatchflush() already calls smbdfreesendio(), so we should not call it again after smbdpostsend() moved it to the batch list.

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:

kthread: consolidate kthread exit paths to prevent use-after-free

Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rbnode with an 8-byte rhashhead in struct pid, shrinking it from 160 to 144 bytes.

struct kthread (without CONFIGBLKCGROUP) is also 144 bytes. With CONFIGSLABMERGEDEFAULT and SLABHWCACHEALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinitynode both sit at offset 0x78.

When a kthread exits via maketaskdead() it bypasses kthreadexit() and misses the affinitynode cleanup. freekthreadstruct() frees the memory while the node is still linked into the global kthreadaffinitylist. A subsequent listdel() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer.

Instead of patching freekthreadstruct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthreadexit() into a macro that calls doexit() and add kthreaddoexit() which is called from doexit() for any task with PFKTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - maketaskdead(), direct doexit(), or kthreadexit().

Replace tokthread() with a new tskiskthread() accessor in the public header. Export doexit() since module code using the kthreadexit() macro now needs it directly.

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

net/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQ

XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpfxdppulldata() or bpfxdpadjusttail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues.

The issue was discovered by the drivers/net/xdp.py selftest, more specifically the testxdpnativetxmb: - The mlx5 driver allocates a pagepool page and initializes it with a frag counter of 64 (pprefcount=64) and the internal frag counter to 0. - The test sends one packet with no payload. - On RX (mlx5eskbfromcqempwrqnonlinear()), mlx5 configures the XDP buffer with the packet data starting in the first fragment which is the page mentioned above. - The XDP program runs and calls bpfxdppulldata() which moves the header into the linear part of the XDP buffer. As the packet doesn't contain more data, the program drops the tail fragment since it no longer contains any payload (pprefcount=63). - mlx5 device skips counting this fragment. Internal frag counter remains 0. - mlx5 releases all 64 fragments of the page but page pprefcount is 63 => negative reference counting error.

Resulting splat during the test:

WARNING: CPU: 0 PID: 188225 at ./include/net/pagepool/helpers.h:297 mlx5epagereleasefragmented.isra.0+0xbd/0xe0 [mlx5core] Modules linked in: [...] CPU: 0 UID: 0 PID: 188225 Comm: ip Not tainted 6.18.0-rc7forupstreammindebug202512081144 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5epagereleasefragmented.isra.0+0xbd/0xe0 [mlx5core] [...] Call Trace: <TASK> mlx5efreerxmpwqe+0x20a/0x250 [mlx5core] mlx5edeallocrxmpwqe+0x37/0xb0 [mlx5core] mlx5efreerxdescs+0x11a/0x170 [mlx5core] mlx5ecloserq+0x78/0xa0 [mlx5core] mlx5eclosequeues+0x46/0x2a0 [mlx5core] mlx5eclosechannel+0x24/0x90 [mlx5core] mlx5eclosechannels+0x5d/0xf0 [mlx5core] mlx5esafeswitchparams+0x2ec/0x380 [mlx5core] mlx5echangemtu+0x11d/0x490 [mlx5core] mlx5echangenicmtu+0x19/0x30 [mlx5core] netifsetmtuext+0xfc/0x240 dosetlink.isra.0+0x226/0x1100 rtnlnewlink+0x7a9/0xba0 rtnetlinkrcvmsg+0x220/0x3c0 netlinkrcvskb+0x4b/0xf0 netlinkunicast+0x255/0x380 netlinksendmsg+0x1f3/0x420 socksendmsg+0x38/0x60 syssendmsg+0x1e8/0x240 syssendmsg+0x7c/0xb0 [...] syssendmsg+0x5f/0xb0 dosyscall64+0x55/0xc70

The problem applies for XDPPASS as well which is handled in a different code path in the driver.

This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDPTX , XDPREDIRECT and XDPPASS). This is basically reverting to the original counting before the commit in the fixes tag.

As fragpage is still pointing to the original tail, the nrfrags parameter to xdpupdateskbfragsinfo() needs to be calculated in a different way to reflect the new nrfrags.

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

drm/display/dpmst: Add protection against 0 vcpi

When releasing a timeslot there is a slight chance we may end up with the wrong payload mask due to overflow if the delayeddestroywork ends up coming into play after a DP 2.1 monitor gets disconnected which causes vcpi to become 0 then we try to make the payload = ~BIT(vcpi - 1) which is a negative shift. VCPI id should never really be 0 hence skip changing the payload mask if VCPI is 0.

Otherwise it leads to <7> [515.287237] xe 0000:03:00.0: [drm:drmdpmstgetportmalloc [drmdisplayhelper]] port ffff888126ce9000 (3) <4> [515.287267] -----------[ cut here ]----------- <3> [515.287268] UBSAN: shift-out-of-bounds in ../drivers/gpu/drm/display/drmdpmsttopology.c:4575:36 <3> [515.287271] shift exponent -1 is negative <4> [515.287275] CPU: 7 UID: 0 PID: 3108 Comm: kworker/u64:33 Tainted: G S U 6.17.0-rc6-lgci-xe-xe-3795-3e79699fa1b216e92+ #1 PREEMPT(voluntary) <4> [515.287279] Tainted: [S]=CPUOUTOFSPEC, [U]=USER <4> [515.287279] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 1645 03/15/2024 <4> [515.287281] Workqueue: drmdpmstwq drmdpdelayeddestroywork [drmdisplayhelper] <4> [515.287303] Call Trace: <4> [515.287304] <TASK> <4> [515.287306] dumpstacklvl+0xc1/0xf0 <4> [515.287313] dumpstack+0x10/0x20 <4> [515.287316] ubsanhandleshiftoutofbounds+0x133/0x2e0 <4> [515.287324] ? drmatomicgetprivateobjstate+0x186/0x1d0 <4> [515.287333] drmdpatomicreleasetimeslots.cold+0x17/0x3d [drmdisplayhelper] <4> [515.287355] mstconnectoratomiccheck+0x159/0x180 [xe] <4> [515.287546] drmatomichelpercheckmodeset+0x4d9/0xfa0 <4> [515.287550] ? wwmutexlock.constprop.0+0x6f/0x1a60 <4> [515.287562] intelatomiccheck+0x119/0x2b80 [xe] <4> [515.287740] ? findheldlock+0x31/0x90 <4> [515.287747] ? lockrelease+0xce/0x2a0 <4> [515.287754] drmatomiccheckonly+0x6a2/0xb40 <4> [515.287758] ? drmatomicaddaffectedconnectors+0x12b/0x140 <4> [515.287765] drmatomiccommit+0x6e/0xf0 <4> [515.287766] ? pfxdrmprintfninfo+0x10/0x10 <4> [515.287774] drmclientmodesetcommitatomic+0x25c/0x2b0 <4> [515.287794] drmclientmodesetcommitlocked+0x60/0x1b0 <4> [515.287795] ? mutexlocknested+0x1b/0x30 <4> [515.287801] drmclientmodesetcommit+0x26/0x50 <4> [515.287804] drmfbhelperrestorefbdevmodeunlocked+0xdc/0x110 <4> [515.287810] drmfbhelperhotplugevent+0x120/0x140 <4> [515.287814] drmfbdevclienthotplug+0x28/0xd0 <4> [515.287819] drmclienthotplug+0x6c/0xf0 <4> [515.287824] drmclientdevhotplug+0x9e/0xd0 <4> [515.287829] drmkmshelperhotplugevent+0x1a/0x30 <4> [515.287834] drmdpdelayeddestroywork+0x3df/0x410 [drmdisplayhelper] <4> [515.287861] processonework+0x22b/0x6f0 <4> [515.287874] workerthread+0x1e8/0x3d0 <4> [515.287879] ? pfxworkerthread+0x10/0x10 <4> [515.287882] kthread+0x11c/0x250 <4> [515.287886] ? pfxkthread+0x10/0x10 <4> [515.287890] retfromfork+0x2d7/0x310 <4> [515.287894] ? pfxkthread+0x10/0x10 <4> [515.287897] retfromforkasm+0x1a/0x30

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

RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGESIZE

The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGESIZE. The core issue is that rxesetpage() is called with mr->pagesize step increments, but the pagelist stores individual struct page pointers, each representing PAGESIZE of memory.

ibsgtopage() has ensured that when i>=1 either a) SG[i-1].dmaend and SG[i].dmaaddr are contiguous or b) SG[i-1].dmaend and SG[i].dmaaddr are mr->pagesize aligned.

This leads to incorrect iova-to-va conversion in scenarios:

1) pagesize < PAGESIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dmaaddr=0x181800, len=0x800 sg[1]: dmaaddr=0x173000, len=0x1000

Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - pageoffset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong)

2) pagesize > PAGESIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dmaaddr=0x18f800, len=0x800 sg[1]: dmaaddr=0x170000, len=0x1000

Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - pageoffset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dmaaddr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong)

Yi Zhang reported a kernel panic[1] years ago related to this defect.

Solution: 1. Replace xarray with pre-allocated rxemrpage array for sequential indexing (all MR page indices are contiguous) 2. Each rxemrpage stores both struct page and offset within the system page 3. Handle MR pagesize != PAGESIZE relationships: - pagesize > PAGESIZE: Split MR pages into multiple system pages - pagesize <= PAGESIZE: Store offset within system page 4. Add boundary checks and compatibility validation

This ensures correct iova-to-va conversion regardless of MR page size and system PAGESIZE relationship, while improving performance through array-based sequential access.

Tests on 4K and 64K PAGESIZE hosts: - rdma-core/pytests $ ./build/bin/runtests.py --dev eth0rxe - blktest: $ TIMEOUT=30 QUICKRUN=1 USERXE=1 NVMETTRTYPES=rdma ./check nvme srp rnbd

[1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/

dm cache policy smq: fix missing locks in invalidating cache blocks

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

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

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

serial: 8250dw: unregister 8250 port if clknotifierregister() fails

dw8250probe() registers the 8250 port via serial8250register8250port() and then, if the device has a clock, registers a clock notifier. If clknotifierregister() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250unregisterport() lives in dw8250remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved privatedata and serialin/serialout callbacks), so any access to that port slot before a rebind is a use-after-free hazard.

Unregister the port on the clknotifierregister() error path.

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

pNFS: Fix use-after-free in pnfsupdatelayout()

When hitting the NFSLAYOUTRETURN branch in pnfsupdatelayout(), the code calls pnfspreparetoretrylayoutget(lo). If it succeeds, pnfsputlayouthdr(lo) is called before tracepnfsupdatelayout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields.

Fix this by moving the tracepoint call before pnfsputlayouthdr(lo).

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

igc: set tx buffer type for SMD frames

Sashiko pointed out that igcfpeinitsmdframe() initializes igctxbuffer fields for an SMD skb, but does not set the buffer type: https://sashiko.dev/#/patchset/20260415025226.114115-1-kohei%40enjuk.jp

Since igctxbuffer entries are reused, a stale XDP or XSK type can remain and make TX completion use the wrong cleanup path.

Set the buffer type to IGCTXBUFFERTYPESKB.

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

net: tls: prevent chain-after-chain in plain text SG

Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link:

This would create a chain where the wrap link points directly to another chain link. The scatterlist API sgnext iterator does not recursively resolve consecutive chain links.

meaning this is illegal input to crypto.

The wrapping link is unnecessary if end = 0. end is the entry after the last one used so end = 0 means there's nothing pushed after the wrap:

end start i v v v [ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap]

Skip the wrapping in this case.

TLS 1.3 can use the "wrapping slot" for it's chaining if end = 0. This avoids the chain-after-chain.

Move the wrap chaining before marking END and chaining off content type, that feels like more logical ordering to me, but should not matter from functional perspective.

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

netfs: Fix netfsreadtopagecache() to pause on subreq failure

Fix netfsreadtopagecache() so that it pauses the generation of new subrequests if an already-issued subrequest fails.

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

ipv6: ioam: refresh hdr pointer before ioam6event()

Reported by Sashiko:

In ipv6hopioam(), the hdr pointer is initialized to point into the skb's linear data buffer. Later, the code calls skbensurewritable(), which might reallocate the buffer:

if (skbensurewritable(skb, optoff + 2 + hdr->optlen)) goto drop;

/ Trace pointer may have changed / trace = (struct ioam6tracehdr )(skbnetworkheader(skb) + optoff + sizeof(hdr));

ioam6filltracedata(skb, ns, trace, true);

ioam6event(IOAM6EVENTTRACE, devnet(skb->dev), GFPATOMIC, (void )trace, hdr->optlen - 2);

If the skb is cloned or lacks sufficient linear headroom, skbensurewritable() will invoke pskbexpandhead(), which reallocates the skb's data buffer and frees the old one, invalidating pointers to it. While the code recalculates the trace pointer immediately after the call to skbensurewritable(), it fails to recalculate the hdr pointer.

This patch fixes the above by recalculating the hdr pointer before passing hdr->optlen to ioam6event(), so that we avoid any UaF.

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

idpf: fix readdevclklock spinlock init in idpfptpinit()

In idpfptpinit(), readdevclklock is initialized after ptpscheduleworker() had already been called (and after idpfptpsettime64() could reach the lock). The PTP aux worker fires immediately upon scheduling and can call into idpfptpreadsrcclkregdirect(), which takes spinlock(&ptp->readdevclklock) on an uninitialized lock, triggering the lockdep "non-static key" warning:

[12973.796587] idpf 0000:83:00.0: Device HW Reset initiated [12974.094507] INFO: trying to register non-static key. ... [12974.097208] Call Trace: [12974.097213] <TASK> [12974.097218] dumpstacklvl+0x93/0xe0 [12974.097234] registerlockclass+0x4c4/0x4e0 [12974.097249] ? lockacquire+0x427/0x2290 [12974.097259] lockacquire+0x98/0x2290 [12974.097272] lockacquire+0xc6/0x310 [12974.097281] ? idpfptpreadsrcclkreg+0xb7/0x150 [idpf] [12974.097311] ? lockdephardirqsonprepare+0xde/0x190 [12974.097318] ? finishtaskswitch.isra.0+0xd2/0x350 [12974.097330] ? pfxptpauxkworker+0x10/0x10 [ptp] [12974.097343] rawspinlock+0x30/0x40 [12974.097353] ? idpfptpreadsrcclkreg+0xb7/0x150 [idpf] [12974.097373] idpfptpreadsrcclkreg+0xb7/0x150 [idpf] [12974.097391] ? kthreadworkerfn+0x88/0x3d0 [12974.097404] ? kthreadworkerfn+0x4e/0x3d0 [12974.097411] idpfptpupdatecachedphctime+0x26/0x120 [idpf] [12974.097428] ? rawspinunlockirq+0x28/0x50 [12974.097436] idpfptpdoauxwork+0x15/0x20 [idpf] [12974.097454] ptpauxkworker+0x20/0x40 [ptp] [12974.097464] kthreadworkerfn+0xd5/0x3d0 [12974.097474] ? pfxkthreadworkerfn+0x10/0x10 [12974.097482] kthread+0xf4/0x130 [12974.097489] ? pfxkthread+0x10/0x10 [12974.097498] retfromfork+0x32c/0x410 [12974.097512] ? pfxkthread+0x10/0x10 [12974.097519] retfromforkasm+0x1a/0x30 [12974.097540] </TASK>

Move the call to spinlockinit() up a bit to make sure readdevclklock is not touched before it's been initialized.

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

spi: fsl-lpspi: terminate the RX channel on TX prepare failure path

When dmaengineprepslavesg() fails for the TX channel, the error path terminates the TX DMA channel but leaves the RX channel running. Since the RX channel was already submitted and issued prior to preparing the TX descriptor, returning -EINVAL causes the SPI core to unmap the DMA buffers while the RX DMA engine continues writing to them, leading to potential memory corruption or use-after-free.

Terminate the RX channel before returning on the TX prepare failure path.

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

bpf: Reject fragmented frames in devmap

Devmap broadcast redirects clone the packet for all but the last destination.

For native XDP, that clone path copies only the linear xdpframe data, while fragmented frames keep skbsharedinfo in tailroom outside the linear area. Cloning such a frame leaves XDPFLAGSHASFRAGS set but without valid frag metadata, and the later free path can interpret uninitialized tail data as skbsharedinfo, leading to an out-of-bounds access during frame return.

Reject fragmented native XDP frames in devmapenqueueclone().

Add the same restriction to the generic XDP clone path in devmapredirectclone(). Generic XDP represents fragmented packets as nonlinear skbs, and rejecting them here keeps clone-based broadcast support aligned between native and generic XDP.

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

RDMA/srpt: Fix srptallocrwctxs() unwind counters

When srptallocrwctxs() fails partway through a multi-buffer indirect descriptor, the unwind path destroys RDMA contexts but leaves stale nrwctx and nrdma values (and a dangling rwctxs pointer). Later sqwravail accounting in srptqueueresponse() or srptwritepending() can then subtract the wrong number of send queue credits.

Reset the counters and clear rwctxs after freeing the heap allocation before returning an error.

ext4: avoid infinite loops caused by residual data

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]

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

net: skmsg: preserve sg.copy across SG transforms

The skmsg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells skmsgcomputedatapointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the skmsg, such as splice-backed file page-cache pages.

Several skmsg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SKMSG verdict can then expose sgvirt(sge) as writable ctx->data and BPF stores can modify the original page cache.

Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new skmsg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, skmsgshiftleft/right(), skmsgxfer(), and tlssplitopenrecord(), including the partial tail entry created during TLS open-record splitting.

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

KVM: SEV: Ignore Port I/O requests of length '0'

Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.

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:

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:

ksmbd: fix signededness bug in smbdirectpreparenegotiation()

smbdirectpreparenegotiation() casts an unsigned u32 value from sp->maxrecvsize and req->preferredsendsize to a signed int before computing mint(int, ...). A maliciously provided preferredsendsize of 0x80000000 will return as smaller than maxrecvsize, and then be used to set the maximum allowed alowed receive size for the next message.

By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow.

This fix replaces mint(int, ...) with mint(u32)

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

ipv6: rpl: reserve maclen headroom when recompressed SRH grows

ipv6rplsrhrcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes).

pskbexpandhead() was gated on segmentsleft == 0, so on earlier segments the push consumed unchecked headroom. Once skbpush() leaves fewer than skb->maclen bytes in front of data, skbmacheaderrebuild()'s call to:

skbsetmacheader(skb, -skb->maclen);

will store (data - head) - maclen into the u16 macheader field, which wraps to ~65530, and the following memmove() writes maclen bytes ~64KiB past skb->head.

A single AFINET6/SOCKRAW/IPV6HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6rthdrrcv.

Fix this by expanding the head whenever the remaining room is less than the push size plus maclen, and request that much extra so the rebuilt MAC header fits afterwards.

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

RDMA/rxe: Validate pad and ICRC before payloadsize() in rxercv

rxercv() currently checks only that the incoming packet is at least headersize(pkt) bytes long before payloadsize() is used.

However, payloadsize() subtracts both the attacker-controlled BTH pad field and RXEICRCSIZE from pkt->paylen:

payloadsize = pkt->paylen - offset[RXEPAYLOAD] - bthpad(pkt) - RXEICRCSIZE

This means a short packet can still make payloadsize() underflow even if it includes enough bytes for the fixed headers. Simply requiring headersize(pkt) + RXEICRCSIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payloadsize() negative and pass an underflowed value to later receive-path users.

Fix this by validating pkt->paylen against the full minimum length required by payloadsize(): headersize(pkt) + bthpad(pkt) + RXEICRCSIZE.

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

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