The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net: hns3: add VLAN id validation before using

Currently, the VLAN id may be used without validation when receive a VLAN configuration mailbox from VF. The length of vlandelfailbmap is BITSTOLONGS(VLANNVID). It may cause out-of-bounds memory access once the VLAN id is bigger than or equal to VLANN_VID.

Therefore, VLAN id needs to be checked to ensure it is within the range of VLANNVID.(CVE-2025-71112)

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

ext4: fix string copying in parseapplysbmountoptions()

strscpypad() can't be used to copy a non-NUL-term string into a NUL-term string of possibly bigger size. Commit 0efc5990bca5 ("string.h: Introduce memtostr() and memtostrpad()") provides additional information in that regard. So if this happens, the following warning is observed:

strnlen: detected buffer overflow: 65 byte read of buffer size 64 WARNING: CPU: 0 PID: 28655 at lib/string_helpers.c:1032 __fortifyreport+0x96/0xc0 lib/stringhelpers.c:1032 Modules linked in: CPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 Not tainted 6.12.54-syzkaller-00144-g5f0270f1ba00 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__fortifyreport+0x96/0xc0 lib/stringhelpers.c:1032 Call Trace: <TASK> __fortifypanic+0x1f/0x30 lib/stringhelpers.c:1039 strnlen include/linux/fortify-string.h:235 [inline] sizedstrscpy include/linux/fortify-string.h:309 [inline] parseapplysbmount_options fs/ext4/super.c:2504 [inline] __ext4fillsuper fs/ext4/super.c:5261 [inline] ext4fillsuper+0x3c35/0xad00 fs/ext4/super.c:5706 gettreebdevflags+0x387/0x620 fs/super.c:1636 vfsgettree+0x93/0x380 fs/super.c:1814 donewmount fs/namespace.c:3553 [inline] pathmount+0x6ae/0x1f70 fs/namespace.c:3880 do_mount fs/namespace.c:3893 [inline] __dosysmount fs/namespace.c:4103 [inline] __sesysmount fs/namespace.c:4080 [inline] __x64sysmount+0x280/0x300 fs/namespace.c:4080 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x64/0x140 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x76/0x7e

Since userspace is expected to provide smountopts field to be at most 63 characters long with the ending byte being NUL-term, use a 64-byte buffer which matches the size of smountopts, so that strscpy_pad() does its job properly. Return with error if the user still managed to provide a non-NUL-term string here.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-71123)

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

RDMA/umad: Reject negative datalen in ibumad_write

ibumadwrite computes datalen from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, datalen can become negative and reach ibcreatesendmad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in allocsendrmpplist().

Add an explicit check to reject negative data_len before creating the send buffer.

KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ibcreatesendmad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spraythread/102 [ 211.365867] ibcreatesendmad+0xa01/0x11b0 [ 211.365887] ibumad_write+0x853/0x1c80(CVE-2026-23243)

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

nvme: fix memory allocation in nvmeprread_keys()

nvmeprreadkeys() takes numkeys from userspace and uses it to calculate the allocation size for rse via structsize(). The upper limit is PRKEYS_MAX (64K).

A malicious or buggy userspace can pass a large numkeys value that results in a 4MB allocation attempt at most, causing a warning in the page allocator when the order exceeds MAXPAGE_ORDER.

To fix this, use kvzalloc() instead of kzalloc().

This bug has the same reasoning and fix with the patch below: https://lore.kernel.org/linux-block/(CVE-2026-23244)

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

media: dvb-core: fix wrong reinitialization of ringbuffer on reopen

dvbdvropen() calls dvbringbufferinit() when a new reader opens the DVR device. dvbringbufferinit() calls initwaitqueuehead(), which reinitializes the waitqueue list head to empty.

Since dmxdev->dvrbuffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from iouring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}.

The waitqueue and spinlock in dvrbuffer are already properly initialized once in dvbdmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions.

Replace the dvbringbufferinit() call in dvbdvropen() with direct assignment of data/size and a call to dvbringbufferreset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock.(CVE-2026-23253)

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

apparmor: fix unprivileged local user can do privileged policy management

An unprivileged local user can load, replace, and remove profiles by opening the apparmorfs interfaces, via a confused deputy attack, by passing the opened fd to a privileged process, and getting the privileged process to write to the interface.

This does require a privileged target that can be manipulated to do the write for the unprivileged process, but once such access is achieved full policy management is possible and all the possible implications that implies: removing confinement, DoS of system or target applications by denying all execution, by-passing the unprivileged user namespace restriction, to exploiting kernel bugs for a local privilege escalation.

The policy management interface can not have its permissions simply changed from 0666 to 0600 because non-root processes need to be able to load policy to different policy namespaces.

Instead ensure the task writing the interface has privileges that are a subset of the task that opened the interface. This is already done via policy for confined processes, but unconfined can delegate access to the opened fd, by-passing the usual policy check.(CVE-2026-23268)

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

perf: Fix _perfeventoverflow() vs perfremovefromcontext() race

Make sure that __perfeventoverflow() runs with IRQs disabled for all possible callchains. Specifically the software events can end up running it with only preemption disabled.

This opens up a race vs perfeventexit_event() and friends that will go and free various things the overflow path expects to be present, like the BPF program.(CVE-2026-23271)

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

drm/vmwgfx: Return the correct value in vmwtranslateptr functions

Before the referenced fixes these functions used a lookup function that returned a pointer. This was changed to another lookup function that returned an error code with the pointer becoming an out parameter.

The error path when the lookup failed was not changed to reflect this change and the code continued to return the PTRERR of the now uninitialized pointer. This could cause the vmwtranslate_ptr functions to return success when they actually failed causing further uninitialized and OOB accesses.(CVE-2026-23317)

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

bpf: Fix a UAF issue in bpftrampolinelinkcgroupshim

The root cause of this bug is that when 'bpflinkput' reduces the refcount of 'shimlink->link.link' to zero, the resource is considered released but may still be referenced via 'tr->progshlist' in 'cgroupshimfind'. The actual cleanup of 'tr->progshlist' in 'bpfshimtramplinkrelease' is deferred. During this window, another process can cause a use-after-free via 'bpftrampolinelinkcgroup_shim'.

Based on Martin KaFai Lau's suggestions, I have created a simple patch.

To fix this: Add an atomic non-zero check in 'bpftrampolinelinkcgroupshim'. Only increment the refcount if it is not already zero.

Testing: I verified the fix by adding a delay in 'bpfshimtramplinkrelease' to make the bug easier to trigger:

static void bpfshimtramplinkrelease(struct bpflink link) { / ... */ if (!shimlink->trampoline) return;

• msleep(100); WARNONONCE(bpftrampolineunlinkprog(&shimlink->link, shimlink->trampoline, NULL)); bpftrampolineput(shimlink->trampoline); }

Before the patch, running a PoC easily reproduced the crash(almost 100%) with a call trace similar to KaiyanM's report. After the patch, the bug no longer occurs even after millions of iterations.(CVE-2026-23319)

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

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

getupperifindexes() iterates over all upper devices and writes their indices into an array without checking bounds.

Also the callers assume that the max number of upper devices is MAXNESTDEV and allocate excludeddevices[1+MAXNESTDEV] on the stack, but that assumption is not correct and the number of upper devices could be larger than MAXNEST_DEV (e.g., many macvlans), causing a stack-out-of-bounds write.

Add a max parameter to getupperifindexes() to avoid the issue. When there are too many upper devices, return -EOVERFLOW and abort the redirect.

To reproduce, create more than MAXNESTDEV(8) macvlans on a device with an XDP program attached using BPFFBROADCAST | BPFFEXCLUDE_INGRESS. Then send a packet to the device to trigger the XDP redirect path.(CVE-2026-23359)

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

bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing

struct bpf_plt contains a u64 target field. Currently, the BPF JIT allocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT buffer.

Because the base address of the JIT buffer can be 4-byte aligned (e.g., ending in 0x4 or 0xc), the relative padding logic in build_plt() fails to ensure that target lands on an 8-byte boundary.

This leads to two issues: 1. UBSAN reports misaligned-access warnings when dereferencing the structure. 2. More critically, target is updated concurrently via WRITEONCE() in bpfarchtextpoke() while the JIT'd code executes ldr. On arm64, 64-bit loads/stores are only guaranteed to be single-copy atomic if they are 64-bit aligned. A misaligned target risks a torn read, causing the JIT to jump to a corrupted address.

Fix this by increasing the allocation alignment requirement to 8 bytes (sizeof(u64)) in bpfjitbinarypackalloc(). This anchors the base of the JIT buffer to an 8-byte boundary, allowing the relative padding math in build_plt() to correctly align the target field.(CVE-2026-23383)

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

Squashfs: check metadata block offset is within range

Syzkaller reports a "general protection fault in squashfscopydata"

This is ultimately caused by a corrupted index look-up table, which produces a negative metadata block offset.

This is subsequently passed to squashfscopydata (via squashfsreadmetadata) where the negative offset causes an out of bounds access.

The fix is to check that the offset is within range in squashfsreadmetadata. This will trap this and other cases.(CVE-2026-23388)

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

crypto: afalg - Fix page reassignment overflow in afalgpulltsgl

When page reassignment was added to afalgpull_tsgl the original loop wasn't updated so it may try to reassign one more page than necessary.

Add the check to the reassignment so that this does not happen.

Also update the comment which still refers to the obsolete offset argument.(CVE-2026-43078)

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

crypto: algif_aead - snapshot IV for async AEAD requests

AF_ALG AEAD AIO requests currently use the socket-wide IV buffer during request processing. For async requests, later socket activity can update that shared state before the original request has fully completed, which can lead to inconsistent IV handling.

Snapshot the IV into per-request storage when preparing the AEAD request, so in-flight operations no longer depend on mutable socket state.(CVE-2026-46028)

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

sched/fair: Clear rel_deadline when initializing forked entities

A yield-triggered crash can happen when a newly forked schedentity enters the fair class with se->reldeadline unexpectedly set.

The failing sequence is:

1. A task is forked while se->rel_deadline is still set.
2. _schedfork() initializes vruntime, vlag and other schedentity state, but does not clear reldeadline.
3. On the first enqueue, enqueueentity() calls placeentity().
4. Because se->reldeadline is set, placeentity() treats se->deadline as a relative deadline and converts it to an absolute deadline by adding the current vruntime.
5. However, the forked entity's deadline is not a valid inherited relative deadline for this new scheduling instance, so the conversion produces an abnormally large deadline.
6. If the task later calls schedyield(), yieldtask_fair() advances se->vruntime to se->deadline.
7. The inflated vruntime is then used by the following enqueue path, where the vruntime-derived key can overflow when multiplied by the entity weight.
8. This corrupts cfsrq->sumwvruntime, breaks EEVDF eligibility calculation, and can eventually make all entities appear ineligible. picknext_entity() may then return NULL unexpectedly, leading to a later NULL dereference.

A captured trace shows the effect clearly. Before yield, the entity's vruntime was around:

9834017729983308

After yieldtaskfair() executed:

se->vruntime = se->deadline

the vruntime jumped to:

19668035460670230

and the deadline was later advanced further to:

19668035463470230

This shows that the deadline had already become abnormally large before yieldtaskfair() copied it into vruntime.

reldeadline is only meaningful when se->deadline really carries a relative deadline that still needs to be placed against vruntime. A freshly forked schedentity should not inherit or retain this state. Clear se->rel_deadline in __schedfork(), together with the other schedentity runtime state, so that the first enqueue does not interpret the new entity's deadline as a stale relative deadline.(CVE-2026-52980)

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

crypto: hisilicon/sec2 - prevent req used-after-free for sec

During packet transmission, if the system is under heavy load, the hardware might complete processing the packet and free the request memory (req) before the transmission function finishes. If the software subsequently accesses this req, a use-after-free error will occur. The qpctx memory exists throughout the packet sending process, so replace the req with the qpctx.(CVE-2026-53055)

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

sctp: validate cached peer INIT chunk length in COOKIE_ECHO processing

When a listening SCTP server processes a COOKIEECHO chunk, the cached peer INIT chunk embedded after the cookie is parsed and its parameters are later walked by sctpprocessinit() using sctpwalk_params().

However, the chunk header length of this cached INIT chunk was not validated against the remaining buffer in the COOKIEECHO payload. If the length field is inflated, the parameter walk can run beyond the actual received data, leading to out-of-bounds reads and potential memory corruption during later parameter handling (e.g. STATECOOKIE processing and kmemdup() copies).

Add a bounds check in sctpunpackcookie() to ensure the cached INIT chunk length does not exceed the available data in the COOKIE_ECHO buffer before it is used.(CVE-2026-53246)

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

serial: 8250dw: unregister 8250 port if clknotifier_register() 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.(CVE-2026-53384)

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 pnfsputlayout_hdr(lo).(CVE-2026-63800)

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 sg_virt(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 tlssplitopen_record(), including the partial tail entry created during TLS open-record splitting.(CVE-2026-63830)

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

scsi: target: iscsi: Validate CHAP_R length before base64 decode

chapservercomputehash() allocates clientdigest as kzalloc(chap->digestsize) and then, for BASE64-encoded responses, passes chapr directly to chapbase64decode() without checking whether the input length could produce more than digest_size bytes of output.

chapbase64decode() writes to the destination unconditionally as long as there is input to consume. With MAXRESPONSELENGTH set to 128 and the "0b" prefix stripped by extractparam(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digestsize=32) this overflows clientdigest by 63 bytes; for MD5 (digestsize=16) the overflow is 79 bytes.

The length check at line 344 fires after the write has already happened.

The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIVROUNDUP(digest_size * 4, 3) before calling the decoder.

Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chapbase64decode() already returns early on '=', so the full original string is still passed to the decoder unchanged.

The mutual CHAP path decodes CHAPC into initiatorchgbinhex, which is kzalloc(CHAPCHALLENGESTRLEN). extractparam() caps initiatorchg at CHAPCHALLENGESTRLEN characters, so at most CHAPCHALLENGESTRLEN-1 base64 characters reach the decoder. The maximum decoded size, DIVROUNDUP((CHAPCHALLENGESTRLEN-1) * 3, 4), is less than CHAPCHALLENGESTRLEN, so no overflow is possible there. A comment is added at the call site to document this.(CVE-2026-63886)

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

scsi: target: iscsi: Bound iscsiencodetextoutput() appends to rspbuf

iscsiencodetextoutput() concatenates "key=value\0" records into login->rspbuf, an 8192-byte kzalloc(MAXKEYVALUEPAIRS) buffer allocated in iscsitallocloginsetup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity:

*length += sprintf(output_buf, "%s=%s", er->key, er->value);
*length += 1;
output_buf = textbuf + *length;

The 8192-byte ceiling at iscsitargetcheckloginrequest() bounds the input Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte "a=b\0" pairs, each unknown key expanding to a 16-byte "a=NotUnderstood\0" output record via iscsiaddnotunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab.

The fix introduces a static iscsiencodetextrecord() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbufsize parameter through iscsiencodetextoutput(). Both call sites in iscsitargethandlecsgzero() (PHASESECURITY) and iscsitargethandlecsgone() (PHASEOPERATIONAL) pass MAXKEYVALUEPAIRS. On overflow the encoder logs the condition, calls iscsireleaseextraresponses() to drop queued records, and returns -1; both caller sites now emit ISCSISTATUSCLSINITIATORERR / ISCSILOGINSTATUSINITERR via iscsittxloginrsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASEOPERATIONAL caller did that; the PHASESECURITY caller is converted to the same shape.)(CVE-2026-63887)

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

scsi: target: iscsi: Fix CRC overread and double-free in iscsithandletext_cmd()

Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1"):

1) DataDigest CRC buffer overread (4 bytes past text_in).

textin is kzalloc()'d at ALIGN(payloadlength, 4). rxsize is then incremented by ISCSICRCLEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rxsize is passed as the buffer length to iscsitcrcbuf():

   if (conn->conn_ops->DataDigest) {
           ...
           rx_size += ISCSI_CRC_LEN;
   }
   ...
   if (conn->conn_ops->DataDigest) {
           data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL);

iscsitcrcbuf() walks rxsize bytes of textin with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C.

Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc().

2) Stale cmd->textinptr re-free (double-free) on ERL>0 bad DataDigest drop.

On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap:

           kfree(text_in);
           return 0;

cmd->textinptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsitsetuptext_cmd(), which unconditionally does

   kfree(cmd->text_in_ptr);
   cmd->text_in_ptr = NULL;

freeing the same pointer a second time. Session teardown via iscsitreleasecmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives.

On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats:

   BUG: KASAN: double-free in iscsit_setup_text_cmd+0x??
   BUG: KASAN: double-free in iscsit_release_cmd+0x??

showing the same pointer freed in the ERL>0 drop path and again in iscsitsetuptextcmd() (next Text Request on the same ITT) and once more in iscsitreleasecmd() (session teardown). On distro kernels with CONFIGSLABFREELISTHARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist.

Fix by clearing cmd->textinptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together.

Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.(CVE-2026-63888)

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

scsi: scsitransportfc: Widen FPIN pname walker counter to u32

An adjacent Fibre Channel fabric actor that can deliver an FPIN ELS frame to an lpfc or qla2xxx Linux initiator can trigger a non-return in the generic FC transport. This is not a local userspace or IP network path; the attacker must be able to inject fabric traffic, for example as a compromised switch or fabric controller, or as a same-zone N_Port on a fabric that permits source spoofing.

The Link-Integrity and Peer-Congestion FPIN walkers used a u8 loop counter against the 32-bit on-wire pnamecount field, and did not bound pnamecount by the descriptor body already validated by the TLV walker. A pname_count of 256 therefore wraps the counter and keeps the loop condition true indefinitely.

Factor the shared pnamelist[] walk into one helper, widen the counter to u32, and clamp pnamecount against the entries that fit in the descriptor body before iterating.(CVE-2026-63889)

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

thunderbolt: property: Cap recursion depth in _tbpropertyparsedir()

A DIRECTORY entry's value field is used as the dir_offset for a recursive call into __tbpropertyparsedir() with no depth counter. A crafted peer that chains DIRECTORY entries into a back-reference loop drives the parser until the kernel stack is exhausted and the guard page fires. Any untrusted XDomain peer (cable, dock, in-line inspector, adjacent host) that reaches the PROPERTIESREQUEST control-plane exchange can trigger this without authentication.

Thread a depth counter through tbpropertyparse() and __tbpropertyparsedir(), and reject blocks that exceed TBPROPERTYMAXDEPTH = 8. That is comfortably larger than any observed legitimate XDomain layout.

Operators who do not need XDomain host-to-host discovery can disable the path entirely with thunderbolt.xdomain=0 on the kernel command line.(CVE-2026-63891)

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

USB: serial: mct_u232: fix memory corruption with small endpoint

The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint.

Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.(CVE-2026-63898)

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

USB: serial: mxuport: fix memory corruption with small endpoint

Make sure that the bulk-out endpoint max packet size is at least eight bytes to avoid user-controlled slab corruption should a malicious device report a smaller size.(CVE-2026-63899)

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

USB: serial: digi_acceleport: fix memory corruption with small endpoints

Add the missing bulk-out buffer size sanity checks to avoid out-of-bounds memory accesses or slab corruption should a malicious device report smaller buffers than expected.(CVE-2026-63901)

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

xfrm: esp: restore combined single-frag length gate

The ESP out-of-place fast path appends the trailer in espoutputhead() before espoutputtail() allocates the destination page frag. The head-side gate currently checks skb->datalen and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->datalen.

Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skbpagefragrefill() may fall back to a single page while the destination sg still spans the combined skb->datalen.

Restore this combined-length page gate for both IPv4 and IPv6.(CVE-2026-63912)

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

ip6: vti: Use ip6tnl.net in vti6changelink().

ip netns add ns1 ip netns add ns2 ip -n ns1 link add vti6test type vti6 remote ::1 local ::2 key 7 ip -n ns1 link set vti6test netns ns2 ip -n ns2 link set vti6_test type vti6 remote ::3 local ::4 key 9 ip netns del ns2 ip netns del ns1 [ 132.495484] ------------[ cut here ]------------ [ 132.497609] kernel BUG at net/core/dev.c:12376!

Commit 61220ab34948 ("vti6: Enable namespace changing") dropped NETIFFNETNSLOCAL from vti6 devices. A vti6 tunnel can then move through IFLANETNSFD. After the move dev_net(dev) points at the new netns while t->net stays at the creation netns.

vti6changelink() and vti6update() still use devnet(dev) and devnet(t->dev). They unlink from one per netns hash and relink into another. The creation netns is left with a stale entry. cleanup_net() of that netns later walks freed memory.

Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). Cross tenant scope on container hosts.(CVE-2026-63917)

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

xfrm: input: hold netns during deferred transport reinjection

Transport-mode reinjection stores a struct net pointer in skb->cb and uses it later from xfrmtransreinject(). That pointer must stay valid until the deferred callback runs.

Take a netns reference when queueing deferred reinjection work and drop it after the callback completes. Use maybegetnet() so the queueing path does not revive a namespace that is already being torn down.

This keeps the existing workqueue design and fixes the netns lifetime handling in one place for all users of xfrmtransqueue_net().(CVE-2026-63919)

In the Linux kernel, ip6datagramrecvspecificctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR} cmsgs (and their IPV62292* legacy counterparts) by trusting the on-wire hdrlen byte (ptr[1]) when computing the putcmsg() length. The length was validated only at parse time (ipv6parsehopopts(), etc.). An nftables payload-write expression can rewrite hdrlen after parsing and before the skb reaches recvmsg; the write itself is in-bounds but put_cmsg() then reads up to ((hdrlen+1) &lt;&lt; 3) = 2040 bytes from an 8-byte header. nftables is reachable from an unprivileged user namespace, so this is an unprivileged slab-out-of-bounds read.(CVE-2026-63920)

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

ip6: vti: Use ip6tnl.net in vti6siocdevprivate().

After patch 1/2 in this series, vti6update() unlinks and relinks the tunnel through t->net. vti6siocdevprivate() still uses devnet(dev) for the collision lookup. For a tunnel moved through IFLANETNSFD, dev_net(dev) is the new netns, not t->net.

SIOCCHGTUNNEL on a migrated tunnel then runs:

net = devnet(dev) /* migrated netns */ t = vti6locate(net, &p1, false) /* misses target in t->net / ... t = netdevpriv(dev) vti6update(t, &p1, false) / mutates t->net's hash */

A caller in the migrated netns picks params that match a tunnel in the creation netns. The lookup in devnet(dev) finds nothing. vti6update() prepends the migrated tunnel at the head of the creation netns hash bucket for those params. Later lookups in the creation netns resolve to the migrated device. xfrm receive delivers the matched packets through a device the caller controls.

Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). Cross tenant scope on container hosts.

Switch the SIOCCHGTUNNEL path on a non fallback device to use t->net for the lookup. The lookup now matches the netns vti6_update() operates on.

Also add nscapable(self->net->userns, CAPNETADMIN) before the lookup. The check at the top of the case is against devnet(dev)->userns, which after migration is the attacker's netns. A caller there can pick params absent from self->net, the lookup returns NULL, t becomes self, and vti6update() inserts the device into the creation netns hash. The new check requires CAPNETADMIN in the creation netns userns too.

SIOCADDTUNNEL and SIOCCHGTUNNEL on the fallback device keep devnet(dev), which equals initnet there.(CVE-2026-63921)

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

ipv6: exthdrs: refresh nh pointer after ipv6hopjumbo()

ipv6hopjumbo() calls pskbtrimrcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.(CVE-2026-63924)

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

bpf: sockmap: fix tail fragment offset in bpfmsgpush_data

When bpfmsgpush_data() inserts data in the middle of a scatterlist entry, it splits the original entry into a left fragment and a right fragment.

The right fragment offset is page-local, but the code advances it with start, which is the message-global insertion point. For inserts into a non-first SG entry, this over-advances the offset and leaves the split layout inconsistent.

Advance the right fragment offset by the fragment-local delta, start - offset, which matches the length removed from the front of the original entry.(CVE-2026-63926)

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

USB: serial: omninet: fix memory corruption with small endpoint

Make sure that the bulk-out buffers are at least as large as the hardcoded transfer size to avoid user-controlled slab corruption should a malicious device report a smaller endpoint max packet size than expected.(CVE-2026-63928)

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

Bluetooth: hcisync: fix UAF in hcilecreatecis_sync

hcilecreatecissync() dereferences conn->conntimeout after releasing both rcureadlock() and hcidevlock(hdev). The conn pointer was obtained from an RCU-protected iteration over hdev->connhash.list and is not valid once these locks are dropped. A concurrent disconnect can free the hci_conn between the unlock and the dereference, causing a use-after-free read.

The cancellation mechanism in hciconndel() cannot prevent this because hcilecreatecispending() queues hcicreatecis_sync with data=NULL:

hci_cmd_sync_queue(hdev, hci_create_cis_sync, NULL, NULL);

While hciconndel() dequeues with data=conn:

hci_cmd_sync_dequeue(hdev, NULL, conn, NULL);

Since NULL != conn, the lookup in hcicmdsynclookup_entry() never matches, and the pending work item is not cancelled.

Fix this by saving conn->conn_timeout into a local variable while the locks are still held, so the stale conn pointer is never dereferenced after unlock.

This is the same class of bug as the one fixed by commit 035c25007c9e ("Bluetooth: hcisync: Fix UAF on lereadfeaturescomplete") which addressed the identical pattern in a different function.

This vulnerability was identified using 0sec.ai, an open-source automated security auditing platform (https://github.com/0sec-labs).(CVE-2026-63944)

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

Bluetooth: ISO: serialize isosockclear_timer with socket lock

isosockclose() calls isosockcleartimer() before acquiring locksock(sk).

isosockcleartimer() reads isopi(sk)->conn twice without the socket lock held:

if (!iso_pi(sk)->conn)
    return;
cancel_delayed_work(&iso_pi(sk)->conn->timeout_work);

Concurrently, isoconndel() executes under locksock(sk) and calls isochandel(), which sets isopi(sk)->conn to NULL and may result in the final reference to the connection being dropped:

CPU0                         CPU1
----                         ----
iso_sock_clear_timer()
  if (conn != NULL) ...      lock_sock(sk)
                               iso_chan_del()
                               iso_pi(sk)->conn = NULL
  cancel_delayed_work(conn)  /* NULL deref or UAF */

iso_pi(sk)->conn is not stable across the unlock window, causing a NULL pointer dereference or use-after-free.

Serialize isosockcleartimer() with the socket lock by moving it inside locksock()/releasesock(), matching the pattern used in isoconn_del() and all other call sites.(CVE-2026-63945)

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

Bluetooth: ISO: fix UAF in isorecvframe

isorecvframe reads conn->sk under isoconnlock but releases the lock before using sk, with no reference held. A concurrent isosockkill() can free sk in that window, causing use-after-free on sk->skstate and sockqueuercvskb().

Fix by replacing the bare pointer read with isosockhold(conn), which calls sockhold() while the spinlock is held, atomically elevating the refcount before the lock drops. Add a dropput label so sock_put() is called on all exit paths where the hold succeeded.(CVE-2026-63946)

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

memfd: deny writeable mappings when implying SEAL_WRITE

When SEALEXEC is added, SEALWRITE is implied to make W^X. But the implied seal is set after the check that makes sure the memfd can not have any writable mappings. This means one can use SEALEXEC to apply SEALWRITE while having writeable mappings.

This breaks the contract that SEAL_WRITE provides and can be used by an attacker to pass a memfd that appears to be write sealed but can still be modified arbitrarily.

Fix this by adding the implied seals before the call for mappingdenywritable() is done.(CVE-2026-63952)

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

USB: serial: cypress_m8: fix memory corruption with small endpoint

Make sure that the interrupt-out endpoint max packet size is at least eight bytes to avoid user-controlled slab corruption or NULL-pointer dereference should a malicious device report a smaller size.(CVE-2026-63956)

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

ipv6: fix possible infinite loop in fib6selectpath()

Found while auditing the same pattern Sashiko reported in rt6fillnode() [1]. Apply the same fix as commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6infouses_dev()").

Writers holding tb6lock can listdelrcu(&first->fib6siblings) without waiting for RCU readers; first->fib6siblings.next then still points into the old ring and this softirq-side walker never reaches &first->fib6siblings as its terminator. fib6purgert() always WRITEONCE()s first->fib6nsiblings to 0 before listdelrcu(), so an inside-loop check is a reliable detach signal.

[1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev(CVE-2026-63968)

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

sctp: fix race between sctpwaitfor_connect and peeloff

sctpwaitforconnect() drops and re-acquires the socket lock while waiting for the association to reach ESTABLISHED state. During this window, another thread can peeloff the association to a new socket via getsockopt(SCTPSOCKOPTPEELOFF), changing asoc->base.sk. After re-acquiring the old socket lock, sctpwaitforconnect() returns success without noticing the migration — the caller then accesses the association under the wrong lock in sctpdatamsgfrom_user().

Add the same sk != asoc->base.sk check that sctpwaitfor_sndbuf() already has, returning an error if the association was migrated while we slept.(CVE-2026-63971)

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

Bluetooth: hcisync: Set HCICMDDRAINWORKQUEUE during device close

Since hcidevclosesync() can now be called during the reset path, we should also set HCICMDDRAINWORKQUEUE. This avoids queuing timeouts while the hdev workqueue is being drained.(CVE-2026-63974)

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

Bluetooth: L2CAP: Fix possible crash on l2capecredconn_rsp

If dcid is received for an already-assigned destination CID the spec requires that both channels to be discarded, but calling l2capchandel may invalidate the tmp cursor created by listforeachentrysafe and in fact it is the wrong procedure as the chan->dcid may be assigned previously it really needs to be disconnected.

Calling l2capchanclone directly may still lead to l2capchandel so instead schedule l2capchantimeout with delay 0 to close the channel asynchronously.(CVE-2026-63975)

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

Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success

l2capecredreconfrsp() returns early on success without clearing chan->ident. Every other L2CAP response handler (l2capecredconnrsp, l2capleconnectrsp, l2capconfig_rsp) clears chan->ident after a successful transaction to prevent the channel from matching subsequent responses with the recycled ident value.

A remote attacker that completed a reconfiguration as the peer can replay a failure response with the stale ident, causing the kernel to match and destroy the already-established channel via l2capchandel(chan, ECONNRESET).

Clear chan->ident for all matching channels on success, and harden the failure path by using l2capchanholdunlesszero() consistent with other L2CAP handlers (l2caplecommand_rej, __l2capgetchanbyident).(CVE-2026-63976)

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

ipv6: rpl: fix hdrlen overflow in ipv6rplsrh_decompress()

ipv6rplsrh_decompress() computes:

outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3);

hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16):

(128 * 16) >> 3 = 256, truncated to 0 as __u8

The caller in ipv6rplsrhrcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6rplsrhcompress() writes into this overlap, corrupting the routing header of the forwarded packet.

The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit.

Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.(CVE-2026-63984)

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

ethtool: eeprom: add more safeties to EEPROM Netlink fallback

The Netlink fallback path for reading module EEPROM (fallbacksetparams()) validates that offset < eepromlen, but does not check that offset + length stays within eepromlen. The ioctl equivalent (ethtoolgetany_eeprom() in ioctl.c) has always enforced both bounds:

if (eeprom.offset + eeprom.len > total_len) return -EINVAL;

This could lead to surprises in both drivers and device FW. Add the missing offset + length validation to fallbacksetparams(), mirroring the ioctl.

Similarly - ethtool core in general, and ethtoolgetanyeeprom() in particular tries to zero-init all buffers passed to the drivers to avoid any extra work of zeroing things out. eepromfallback() uses a plain kmalloc(), change it to zalloc.(CVE-2026-63985)

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

tunnels: do not assume transport header in iptunnelpmtudcheck_icmp()

In some cases, iptunnelpmtudcheck_icmp() can be called while skb transport header is not set.

This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535.

Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part.

Note that iptunnelpmtudcheck_icmpv6()) is fine.(CVE-2026-63992)

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

vxlan: do not reuse cached iphdr() value after skbtunnelcheckpmtu()

skbtunnelcheck_pmtu() can change skb->head.

Reusing oldiph afer skbtunnelcheckpmtu() can cause an UAF.

Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c.

Found by Sashiko.(CVE-2026-63993)

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

tunnels: load network headers after skbcow() in iptunnelpmtudbuildicmpv6

Sashiko found that iptunnelpmtudbuildicmp() and iptunnelpmtudbuildicmpv6() were caching iphdr() and ipv6hdr() before an skb_cow() call which can reallocate skb->head.

Fix this possible UAF by initializing the local variables after the skb_cow() call.

Remove skbresetnetwork_header() calls which were not needed.(CVE-2026-63994)

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

ipv4: free net->ipv4.sysctllocalreservedports after unregisternetsysctltable()

ipv4sysctlexitnet() is currently freeing net->ipv4.sysctllocalreservedports too soon.

Only after unregisternetsysctltable() we can be sure no threads can possibly use the sysctls, including /proc/sys/net/ipv4/iplocalreservedports.(CVE-2026-64002)

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

scsi: core: Run queues for all non-SDEVDEL devices from scsirunhostqueues

While a SCSI host is in a recovery state, scsimqrequeuecmd() will not set the requeue list for a requeued command to be kicked in the future. The expectation is a call to scsirunhostqueues() will kick all SCSI devices once the recovery state is cleared.

However, scsirunhostqueues() uses shostforeachdevice() which uses scsideviceget() and so will ignore devices in a partially removed state like SDEV_CANCEL. But these devices may also have requeued requests, leaving their requests stuck from not being kicked and causing the removal process of the device to hang.

scsirunhostqueues() needs to run against more devices than the macro shostforeachdevice() allows. Instead of using the too limiting scsideviceget() state checks, only ignore devices in SDEVDEL state or when unable to acquire a reference. Attempt to run the queues for all other devices when scsirunhostqueues() is called.(CVE-2026-64003)

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

security/keys: fix missed RCU read section on lookup

Nicholas Carlini reports that the keyring code calls assocarrayfind() in findkeytoupdate() without holding the RCU read lock, while the assocarray_gc() code really is designed around removing the node from the tree and then freeing it after an RCU grace-period.

The regular key handling doesn't see this because holding the keyring semaphore hides any lifetime issues, but the persistent key handling uses a different model.

Instead of extending the keyring locking, just do the simple RCU locking that the assoc_array was designed for.(CVE-2026-64015)

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

bpf, skmsg: fix verdict skdataready racing with ktls rx

skpsockstrpdataready() already checks tlsswhasctxrx() and defers to psock->saveddataready when a TLS RX context is present, avoiding a conflict with the TLS strparser's ownership of the receive queue (commit e91de6afa81c, "bpf: Fix running sk_skb program types with ktls").

skpsockverdictdataready() has no equivalent guard. When a socket is inserted into a sockmap (BPFSKSKBVERDICT) before TLS RX is configured, tlsswstrparserarm() saves skpsockverdictdataready as rxctx->saveddata_ready. On data arrival:

tlsdataready -> tlsstrpdataready -> tlsrxmsgready -> saveddataready() = skpsockverdictdataready() -> tcpreadskb() drains skreceivequeue via __skbunlink() without calling tcpeatskb(), so copiedseq is not advanced.

tlsstrpmsgload() then finds tcpinq() >= fulllen (stale), calls tcprecvskb() on the now-empty queue, hits WARNONONCE(!first), and returns with rxctx->strp.anchor.fraglist pointing at a psock-owned (potentially freed) skb. tlsdecryptsg() subsequently walks that fraglist: use-after-free.

Apply the same fix as skpsockstrpdataready(): if a TLS RX context is present, call psock->saveddataready (sockdefreadable) to wake recv() waiters and return immediately, leaving the receive queue untouched. TLS retains sole ownership of the queue and decrypts the record normally through tlsswrecvmsg().(CVE-2026-64025)

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

bridge: mcast: Fix a possible use-after-free when removing a bridge port

When per-VLAN multicast snooping is enabled, the bridge iterates over all the bridge ports, disables the per-port multicast context on each port and enables the per-{port, VLAN} multicast contexts instead. The reverse happens when per-VLAN multicast snooping is disabled.

When global multicast snooping is enabled, the bridge iterates over all the bridge ports and enables the per-port multicast context on each port. The reverse happens when multicast snooping is disabled.

The above scheme can result in a situation where both types of contexts (per-port and per-{port, VLAN}) are enabled on a single bridge port:

# ip link add name br1 up type bridge mcastsnooping 1 mcastquerier 1 vlanfiltering 1 # ip link add name dummy1 up master br1 type dummy # ip link set dev br1 type bridge mcastvlansnooping 1 # ip link set dev br1 type bridge mcastsnooping 0 # ip link set dev br1 type bridge mcast_snooping 1

This is not intended and it is a problem since the commit cited below. Prior to this commit, when removing a bridge port, brmulticastdisable_port() would disable the per-port multicast context and the per-{port, VLAN} multicast contexts would get disabled when flushing VLANs.

After this commit, brmulticastdisable_port() only disables the per-port multicast context if per-VLAN multicast snooping is disabled. If both types of contexts were enabled on the port when it was removed, the per-port multicast context would remain enabled when freeing the bridge port, leading to a use-after-free [1].

Fix by preventing the bridge from enabling / disabling the per-port multicast contexts when toggling global multicast snooping if per-VLAN multicast snooping is enabled.

[1] ODEBUG: free active (active state 0) object: ffff88810f8bda78 object type: timerlist hint: brip6multicastportqueryexpired (net/bridge/brmulticast.c:1927) WARNING: lib/debugobjects.c:629 at debugprint_object+0x1b1/0x3e0, CPU#5: swapper/5/0 [...] Call Trace: <IRQ> __debugchecknoobjfreed (lib/debugobjects.c:1116) kfree (mm/slub.c:2620 mm/slub.c:6250 mm/slub.c:6565) kobjectcleanup (lib/kobject.c:689) rcudobatch (kernel/rcu/tree.c:2617) rcucore (kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) _irqexitrcu (kernel/softirq.c:656 kernel/softirq.c:496 kernel/softirq.c:735) irqexitrcu (kernel/softirq.c:752) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1061 (discriminator 47) arch/x86/kernel/apic/apic.c:1061 (discriminator 47)) </IRQ>(CVE-2026-64032)

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 sg_next iterator does not recursively resolve consecutive chain links, meaning this is illegal input to crypto. The wrapping link is unnecessary if end = 0. TLS 1.3 can use the "wrapping slot" for its chaining if end = 0, which avoids the chain-after-chain.(CVE-2026-64046)

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

net: tls: fix off-by-one in sgchain entry count for wrapped skmsg ring

When an skmsg scatterlist ring wraps (sg.end < sg.start), tlspushrecord() chains the tail portion of the ring to the head using sgchain(). An extra entry in the sg array is reserved for this:

struct skmsgsg { [...] /* The extra two elements: * 1) used for chaining the front and sections when the list becomes * partitioned (e.g. end < start). The crypto APIs require the * chaining; * 2) to chain tailer SG entries after the message. */ struct scatterlist data[MAXMSGFRAGS + 2];

The current code uses MAXSKBFRAGS + 1 as the ring size:

sg_chain(&msg_pl->sg.data[msg_pl->sg.start],
         MAX_SKB_FRAGS - msg_pl->sg.start + 1,
         msg_pl->sg.data);

This places the chain pointer at

sgchain(data[start], (MAXSKBFRAGS - msgstart + 1) .. = &data[start] + (MAXSKBFRAGS - msgstart + 1) - 1 = data[start + (MAXSKBFRAGS - start + 1) - 1] = data[MAXSKB_FRAGS]

instead of the true last entry. This is likely due to a "race" of the commit under Fixes landing close to commit 031097d9e079 ("bpf: sk_msg, zap ingress queue on psock down")

Convert to ARRAY_SIZE and drop the data[start] / - start (as suggested by Sabrina).(CVE-2026-64047)

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

irqwork: Fix use-after-free in irqworksingle() on PREEMPTRT

On PREEMPTRT, non-HARD irqwork runs in per-CPU kthreads via runirqworkd(), so irqworksync() uses rcuwait() to wait for BUSY==0.

After irqworksingle() clears BUSY via atomiccmpxchg(), it still dereferences @work for irqworkishard() and rcuwaitwakeup().

An irqworksync() caller on another CPU that enters after BUSY is cleared can observe BUSY==0 immediately, return, and free the work before those accesses complete — causing a use-after-free.

Fix this by wrapping runirqworkd() in guard(rcu)() so that the entire irqworksingle() execution is within an RCU read-side critical section. Then add synchronizercu() in irqworksync() after rcuwaitwait_event() to ensure the caller waits for the RCU grace period before returning, preventing premature frees.(CVE-2026-64073)

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

netfilter: bridge: eb_tables: close module init race

sashiko reports for unrelated patch: Does the core ebtables initialization in ebtables.c suffer from a similar race? Once nfregistersockopt() completes, the sockopts are exposed globally.

sockopt has to be registered last, just like in ip/ip6/arptables.(CVE-2026-64076)

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

netfilter: ebtables: move to two-stage removal scheme

Like previous patches for xtables, follow same pattern in ebtables. We can't reuse xt helpers: ebttable struct layout is incompatible.

table->ops assignment is now done while still holding the ebt mutex to make sure we never expose partially-filled table struct.(CVE-2026-64077)

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

batman-adv: tt: fix negative ttbufflen

batadvorignode::ttbufflen was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer.

In batadvsendotherttresponse(), ttbufflen is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadvttpreparetvlvglobal_data() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized.

Using an u16 avoids this type confusion and ensures that no (negative) sign extension is performed in batadvsendotherttresponse().(CVE-2026-64088)

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

batman-adv: tt: fix negative lastchangesetlen

batadvpivtt::lastchangesetlen len was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer.

In batadvsendmyttresponse(), lastchangesetlen is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadvttpreparetvlvlocal_data() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized.

Using an u16 avoids this type confusion and ensures that no (negative) sign extension is performed in batadvsendmyttresponse().(CVE-2026-64089)

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

batman-adv: bla: avoid double decrement of bla.num_requests

The bla.numrequests is increased when no requestsent was in progress. And it is decremented in various places (announcement was received, backbone is purged, periodic work). But the check if the requestsent is actually set to a specific state and the atomicdec/_inc are not safe because they are not atomic (TOCTOU) and multiple such code portions can run concurrently.

At the same time, it is necessary to modify requestsent (state) and bla.numrequests atomically. Otherwise batadvblasendrequest() might set requestsent to 1 and is interrupted. batadvhandleannounce() can then set requestsent back to 0 and decrement numrequests before batadvblasend_request() incremented it.

The two operations must therefore be locked. And since state (requestsent) and waitperiods are only accessed inside this lock, they can be converted to simpler datatypes. And to avoid that the bla.numrequests is touched by a parallel running context with a valid backbonegw reference after batadvblapurgebackbonegw() ran, a third state "stopped" is required to correctly signal that a backbone_gw is in the state of being cleaned up.(CVE-2026-64095)

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

drm/amd/display: Validate GPIO pin LUT table size before iterating

[Why&How] The GPIO pin table parsers in getgpioi2cinfo() and biosparsergetgpiopininfo() derive an element count from the VBIOS tableheader.structuresize field, then iterate over gpiopin[] entries. However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read.

Fix this by calling biosgetimage() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions.

(cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)(CVE-2026-64097)

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

drm/virtio: use uninterruptible resv lock for plane updates

virtiogpucursorplaneupdate() and virtiogpuresourceflush() lock the framebuffer BO's dmaresv via virtiogpuarraylockresv() and ignore its return value. The function can fail with -EINTR from dmaresvlockinterruptible() (signal during lock wait) or with -ENOMEM from dmaresvreservefences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dmaresvaddfence(), which requires the lock held; with lockdep enabled this trips dmaresvassertheld():

WARNING: drivers/dma-buf/dma-resv.c:296 at dmaresvaddfence+0x71e/0x840 Call Trace: virtiogpuarrayaddfence virtiogpuqueuectrlsgs virtiogpuqueuefencedctrlbuffer virtiogpucursorplaneupdate drmatomichelpercommitplanes drmatomichelpercommittail committail drmatomichelpercommit drmatomiccommit drmatomichelperupdateplane __setplaneatomic drmmode_cursoruniversal drmmodecursorcommon drmmodecursorioctl drmioctl __x64sysioctl

Beyond the WARN, mutating the dma_resv fence list without the lock races with concurrent readers/writers and can corrupt the list.

Both call sites run inside the .atomicupdate plane callback, which DRM atomic helpers do not allow to fail (by the time it runs, the commit has been signed off to userspace and there is no clean rollback path). Moving the lock acquisition to .preparefb was rejected because the broader lock scope deadlocks against other BO locking paths in the same atomic commit.

Introduce virtiogpulockoneresvuninterruptible() that uses dmaresvlock() instead of dmaresvlockinterruptible(). This eliminates the -EINTR failure mode -- the realistic syzbot trigger -- without extending the lock hold across the commit. The helper locks a single BO and rejects nents > 1 with -EINVAL; both fix sites lock exactly one BO.

Use it from virtiogpucursorplaneupdate() and virtiogpuresourceflush(); check the return value to handle the remaining -ENOMEM case from dmaresvreservefences() by freeing the objs and skipping the plane update for that frame. The framebuffer BOs touched here are not shared with other contexts and lock contention is expected to be brief, so the loss of signal-interruptibility is acceptable.

Other callers of virtiogpuarraylockresv() (the ioctl paths) continue to use the interruptible variant.

The bug was reported by syzbot, triggered via fault injection (failnth) on the DRMIOCTLMODECURSOR path, which forces the -ENOMEM branch in dmaresvreserve_fences().(CVE-2026-64098)

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

KVM: arm64: vgic-its: Reject restored DTE with out-of-range numeventidbits

Userspace can restore an ITS Device Table Entry whose Size field encodes more EventID bits than the virtual ITS supports. The live MAPD path rejects that state, but vgicitsrestoredte() accepts it and stores the out-of-range value in dev->numeventid_bits.

Reject restored DTEs with numeventidbits > VITSTYPERIDBITS before allocating the device. This mirrors the MAPD check and prevents the restored state from reaching vgicitsrestoreitt(), where the unchecked value can be converted into an oversized scanits_table() range.(CVE-2026-64106)

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

afunix: Fix UAF read of tail->len in unixstreamdatawait()

unixstreamdatawait() does skbpeektail(&sk->skreceivequeue) without holding any lock that prevents SKBs on that queue from being dequeued and freed. This has been the case since commit 79f632c71bea ("unix/stream: fix peeking with an offset larger than data in queue"). The first consequence of this is that the pointer comparison tail != last can be false even if last semantically refers to an already-freed SKB while tail is a new SKB allocated at the same address; which can cause unixstreamdatawait() to wrongly keep blocking after new data has arrived, but only in a weird scenario where a peeking recv() and a normal recv() on the same socket are racing, which is probably not a real problem.

But since commit 2b514574f7e8 ("net: afunix: implement splice for stream afunix sockets"), tail is actually dereferenced, which can cause UAF in the following race scenario (where testsetup() runs single-threaded, and afterwards, testthread1() and test_thread2() run concurrently in two threads:

static int socks[2];
void test_setup(void) {
  socketpair(AF_UNIX, SOCK_STREAM, 0, socks);
  send(socks[1], "A", 1, 0);
  int peekoff = 1;
  setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, &peekoff, sizeof(peekoff));
}
void test_thread1(void) {
  char dummy;
  recv(socks[0], &dummy, 1, MSG_PEEK);
}
void test_thread2(void) {
  char dummy;
  recv(socks[0], &dummy, 1, 0);
  shutdown(socks[1], SHUT_WR);
}

when racing like this:

thread1                       thread2
unix_stream_read_generic
  mutex_lock(&u->iolock)
  skb_peek(&sk->sk_receive_queue)
  skb_peek_next(skb, &sk->sk_receive_queue)
  mutex_unlock(&u->iolock)
                              unix_stream_read_generic
                                unix_state_lock(sk)
                                skb_peek(&sk->sk_receive_queue)
                                unix_state_unlock(sk)
  unix_stream_data_wait
    unix_state_lock(sk)
    tail = skb_peek_tail(&sk->sk_receive_queue)
                                spin_lock(&sk->sk_receive_queue.lock)
                                __skb_unlink(skb, &sk->sk_receive_queue)
                                spin_unlock(&sk->sk_receive_queue.lock)
                                consume_skb(skb) [frees the SKB]
    `tail != last`: false
    `tail`: true
    `tail->len != last_len` ***UAF***

Fix the UAF by removing the read of tail->len; checking tail->len would only make sense if SKBs in the receive queue of a UNIX socket could grow, which can no longer happen.

Kuniyuki explained:

> When commit 869e7c62486e ("net: afunix: implement stream sendpage > support") added sendpage() support, data could be appended to the last > skb in the receiver's queue. > > That's why we needed to check if the length of the last skb was changed > while waiting for new data in unixstreamdatawait(). > > However, commit a0dbf5f818f9 ("afunix: Support MSGSPLICEPAGES") and > commit 57d44a354a43 ("unix: Convert unixstreamsendpage() to use > MSGSPLICE_PAGES") refactored sendmsg(), and now data is always added > to a new skb.

That means this fix is not suitable for kernels before 6.5.(CVE-2026-64109)

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

rbd: eliminate a race in lock_dwork draining on unmap

Given how rbdlockaddrequest() and rbdimgexclusivelock() are written, lockdwork may be (re)queued more than it's actually needed: for example in case a new I/O request comes in while we are in the middle of rbdacquirelock() on behalf of another I/O request. This is expected and with rbdreleaselock() preemptively canceling lockdwork is benign under normal operation.

A more problematic example is maybekickacquire():

if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {
        dout("%s rbd_dev %p kicking lock_dwork\n", __func__, rbd_dev);
        mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0);
}

It's not unrealistic for lockdwork to get canceled right after delayedworkpending() returns true and for moddelayed_work() to requeue it right there anyway. This is a classic TOCTOU race.

When it comes to unmapping the image, there is an implicit assumption of no self-initiated exclusive lock activity past the point of return from rbddevimageunlock() which unlocks the lock if it happens to be held. This unlock is assumed to be final and lockdwork (as well as all other exclusive lock tasks, really) isn't expected to get queued again. However, lockdwork is canceled only in canceltaskssync() (i.e. later in the unmap sequence) and on top of that the cancellation can get in effect nullified by maybekickacquire(). This may result in rbdacquirelock() executing after rbddevdevicerelease() and rbddevimage_release() run and free and/or reset a bunch of things. One of the possible failure modes then is a violated

rbd_assert(rbd_image_format_valid(rbd_dev->image_format));

in rbddevheaderinfo() which is called via rbddevrefresh() from rbdpostacquireaction().

Redo exclusive lock task draining to provide saner semantics and try to meet the assumptions around rbddevimage_unlock().(CVE-2026-64112)

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

ixgbevf: fix use-after-free in VEPA multicast source pruning

ixgbevfcleanrx_irq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor:

dev_kfree_skb_irq(skb);
continue;

The skb pointer is declared outside the while loop and persists across iterations. Because the continue skips the "skb = NULL" reset at the bottom of the loop, the next iteration enters the "else if (skb)" path and calls ixgbevfaddrxfrag() on the freed skb, dereferencing skbshinfo(skb)->nr_frags - a use-after-free in NAPI softirq context.

The sibling driver iavf already handles this correctly by nulling the pointer before continuing. Apply the same pattern here.

I do not have ixgbevf hardware; the bug was found by static analysis (scandropcontinueloops.py + semgrep dropcontinueinloop, multi-tool corroboration with the highest score in the scan). The UAF was confirmed under KASAN by loading a test module that reproduces the exact code pattern (alloc skb, kfreeskb, then read skbshinfo(skb)->nr_frags):

BUG: KASAN: slab-use-after-free in ixgbevfuaftest_init+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90)

QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF driver does not include the VEPA source pruning path, so a full end-to-end reproduction with emulated hardware was not possible.(CVE-2026-64113)

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

ipv4: raw: reject IP_HDRINCL packets with ihl < 5

rawsendhdrinc() validates that the caller-supplied IPv4 header fits within the message length:

iphlen = iph->ihl * 4;
err = -EINVAL;
if (iphlen > length)
    goto error_free;

if (iphlen >= sizeof(*iph)) {
    /* fix up saddr, tot_len, id, csum, transport_header */
}

It does not, however, reject ihl < 5. For such a packet the "if (iphlen >= sizeof(*iph))" branch is skipped, leaving the crafted iphdr untouched, but the packet is still handed to __iplocalout() and onward. Downstream consumers that read iph->ihl assume a sane value: net/ipv4/ah4.c:ahoutput() in particular subtracts sizeof(struct iphdr) from topiph->ihl * 4 and passes the (signed-int-negative, then cast to sizet) result to memcpy(), producing an OOB access of length close to SIZEMAX and a host kernel panic.

An IPv4 header with ihl < 5 is malformed by definition (RFC 791: "Internet Header Length is the length of the internet header in 32 bit words ... Note that the minimum value for a correct header is 5."). The kernel should not be willing to inject such a packet into its own output path.

Reject "iphlen < sizeof(*iph)" alongside the existing "iphlen > length" check. This matches the principle that locally constructed packets that re-enter the IP stack must pass the same basic sanity tests that a foreign packet would be subjected to.

Once this lands, the "if (iphlen >= sizeof(*iph))" wrapper around the fixup branch becomes redundant; left in place to keep the patch minimal and backport-friendly. A follow-up can unwrap it.

Note that commit 86f4c90a1c5c ("ipv4, ipv6: ensure raw socket message is big enough to hold an IP header") ensures the message buffer is large enough to hold an iphdr, but does not constrain the self-reported iph->ihl.

Reachability: the malformed packet source is any caller with CAPNETRAW, including an unprivileged process in a user+net namespace on a kernel with CONFIGUSERNS=y. The reproduced AH crash also requires a matching xfrm AH policy on the outgoing route; a container granted CAPNETADMIN can install that state and policy in its netns. Loopback bypasses xfrm_output, so the trigger uses a real netdev.

Reproduced on UML + KASAN: kernel-mode fault at addr 0x0 with memcpyorig at the crash site. Same shape reproduces inside a rootless Docker container with --cap-add NETADMIN on a stock distro kernel.(CVE-2026-64114)

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

qed: fix double free in qedcxttables_alloc()

If one of the later PF or VF CID bitmap allocations fails, qedcidmapalloc() jumps to cidmapfail and frees the previously allocated CID bitmaps before returning an error. qedcxttablesalloc() then calls qedcxtmngrfree(), which invokes qedcidmapfree() again.

Fix this by setting each CID bitmap pointer to NULL after bitmap_free() to avoid double free.

The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc3.

Runtime reproduction was not attempted because exercising the failing allocation path requires device-specific setup.(CVE-2026-64118)

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

Bluetooth: MGMT: validate Add Extended Advertising Data length

MGMTOPADDEXTADVDATA is registered as a variable-length command, with MGMTADDEXTADVDATASIZE as the fixed header size. The handler then uses cp->advdatalen and cp->scanrsplen to validate and copy cp->data, but it never checks that those bytes are part of the mgmt command payload.

A short command can therefore make addextadvdata() pass an out-of-bounds pointer into tlvdataisvalid(). If the bytes beyond the command buffer are addressable, they can also be copied into the advertising instance as scan response data, where the caller can read them back via MGMTOPGETADVINSTANCE. The trigger requires CAPNETADMIN in the initial user namespace; KASAN reports an 8-byte slab-out-of-bounds read.

Reject commands whose length does not match the fixed header plus both advertising data lengths before parsing cp->data.(CVE-2026-64126)

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

smb: client: protect tccount increment in smb2findsmbsesstconunlocked()

Commit 96c4af418586 ("cifs: Fix locking usage for tcon fields") refactored cifs code to change cifstcpseslock for tclock around tc_count changes.

There was missing lock around tccount increment inside smb2findsmbsesstconunlocked().(CVE-2026-64136)

In the Linux kernel, an out-of-bounds read vulnerability exists in the i2c-stub driver. The I2CSMBUSI2CBLOCKDATA case in stubxfer() function (drivers/i2c/i2c-stub.c) uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2CSMBUSBLOCKMAX (32), which is the limit of the union i2csmbusdata.block buffer. A local user with access to /dev/i2c-* devices can issue an I2CSMBUS ioctl with I2CSMBUSI2CBLOCKDATA and data->block[0] > 32, causing stubxfer() to read or write past the end of the union i2csmbusdata.block buffer, resulting in a stack out-of-bounds access. This vulnerability affects confidentiality, integrity, and availability.(CVE-2026-64191)

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

drm/amd/display: Validate payload length and linkindex in dcprocessdmubauxtransferasync

[Why&How] dcprocessdmubauxtransfer_async() copies payload->length bytes into a 16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which is a no-op in release builds. If a caller ever passes length > 16 this results in a stack buffer overflow via memcpy.

Additionally, linkindex is used to dereference dc->links[] without bounds checking against dc->linkcount, risking an out-of-bounds access.

Replace the ASSERT with a hard runtime check that returns false when payload->length exceeds the destination buffer size, and add a bounds check for link_index before it is used.

(cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)(CVE-2026-64219)

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

octeontx2-pf: avoid double free of pool->stack on AQ init failure

otx2poolaqinit() frees pool->stack when mailbox sync or retry allocation fails, but leaves the pointer unchanged. Later, otx2sqaurapoolinit() unwinds the partial setup through otx2aurapoolfree(), which frees pool->stack again. The CN20K-specific cn20kpoolaq_init() implementation has the same bug in its corresponding error path.

Set pool->stack to NULL immediately after the local free so the shared cleanup path does not free the same stack again while cleaning up partially initialized pool state.

The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc3.

Runtime validation was not performed because reproducing this path requires OcteonTX2/CN20K hardware.(CVE-2026-64222)

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

Input: elan_i2c - 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.(CVE-2026-64237)

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

KVM: x86: hyper-v: Bound the bank index when querying sparse banks

When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096.

Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU.

================================================================== BUG: KASAN: use-after-free in hvisvpinsparseset+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hypervevmcs/2802

CPU: 12 UID: 1000 PID: 2802 Comm: hypervevmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dumpstacklvl+0x51/0x60 printreport+0xcb/0x5d0 kasanreport+0xb4/0xe0 kasancheckrange+0x35/0x1b0 hvisvpinsparseset+0x85/0x100 [kvm] kvmhvflushtlb+0xe9e/0x16c0 [kvm] kvmhvhypercall+0xe6b/0x1e60 [kvm] vmxhandleexit+0x485/0x1b60 [kvmintel] kvmarchvcpuioctlrun+0x22e3/0x5070 [kvm] kvmvcpuioctl+0x5d0/0x10c0 [kvm] __x64sysioctl+0x129/0x1a0 dosyscall64+0xb9/0xcf0 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf </TASK>

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint

Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask.

sean: add KASAN splat, drop comment, add assert, massage changelog

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

NFSv4: include MAYWRITE in open permission mask for OTRUNC

POSIX requires write permission to truncate a file, so an open() that specifies OTRUNC must be authorized for write access regardless of the OACCMODE access mode.

nfsopenpermissionmask() builds the access mask passed to nfsmayopen(), which is the local authorization gate for OPENs the client serves itself from a cached write delegation via the canopendelegated() path in nfs4tryopencached(). The mask is derived from OACCMODE alone, so an open(ORDONLY | OTRUNC) against a file the caller cannot write requests only MAYREAD and passes the local check. The OPEN is then satisfied locally and the truncation is issued to the server as a SETATTR(size=0) over the delegation stateid, which the server accepts under standard write-delegation semantics. POSIX requires that this open fail with EACCES.

Include MAYWRITE in the mask whenever OTRUNC is set so the local check matches the access the server would have enforced.(CVE-2026-64298)

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

tracing: Prevent out-of-bounds read in glob matching

String event fields are not necessarily NUL-terminated, so the filter predicate functions (filterpredstring(), filterpredstrloc() and filterpredstrrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it.

regexmatchglob() was the exception: it ignored the length and called globmatch(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in globmatch(), reached via regexmatchglob() and filtermatchpreds() from the xfslookup tracepoint.

Add a length-bounded globmatchlen() and use it from regexmatchglob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour.(CVE-2026-64299)

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

crypto: qat - validate RSA CRT component lengths

The generic RSA key parser (rsahelper.c) bounds each CRT component (p, q, dp, dq, qinv) by the modulus size nsz, but qatrsasetkeycrt() allocates half-size DMA buffers (keysz / 2) and right-aligns each component with:

memcpy(dst + half_key_sz - len, src, len)

When a CRT component is larger than halfkeysz the subtraction underflows and memcpy writes past the DMA buffer, causing memory corruption.

Add a len > halfkeysz check next to the existing !len check for each of the five CRT components so the driver falls back to the non-CRT path instead of writing out of bounds.(CVE-2026-64304)

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

crypto: qat - protect service table iterations with service_lock

The servicetable list is protected by servicelock when entries are added or removed (in adfserviceadd() and adfserviceremove()), but several functions iterate over the list without holding this lock.

A concurrent adfserviceregister() or adfserviceunregister() call could modify the list during traversal, leading to list corruption or a use-after-free.

Fix this by holding servicelock across all listforeachentry() iterations of servicetable in adfdevinit(), adfdevstart(), adfdevstop(), adfdevshutdown(), adfdevrestartingnotify(), adfdevrestartednotify(), and adferror_notifier().

The lock ordering is safe: callers of the static helpers (adfdevup() and adfdevdown()) acquire statelock before servicelock, and no eventhld callback or servicelock holder ever acquires state_lock in the reverse order.(CVE-2026-64305)

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

crypto: drbg - Fix returning success on failure in CTR_DRBG

drbgctrgenerate() sometimes returns success when it fails, leaving the output buffer uninitialized. Fix it.(CVE-2026-64306)

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

crypto: pcrypt - restore callback for non-parallel fallback

pcrypt installs pcryptaeaddone() on the child AEAD request before trying to submit it through padata. If padatadoparallel() returns -EBUSY, pcrypt falls back to calling the child AEAD directly.

That fallback must not keep the padata completion callback. Otherwise an asynchronous completion runs pcryptaeaddone() even though the request was never enrolled in padata.

Restore the original request callback and callback data before calling the child AEAD directly. This keeps the fallback path aligned with a direct AEAD request while leaving the parallel path unchanged.(CVE-2026-64312)

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

crypto: ecc - Fix carry overflow in vli multiplication

The carry flag calculation fails when r01.m_high is saturated (0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows.

The condition (r01.mhigh < product.mhigh) doesn't handle the case where r01.mhigh == product.mhigh and an additional carry exists from lower-bit overflow.

When commit 3c4b23901a0c ("crypto: ecdh - Add ECDH software support") introduced crypto/ecc.c, it split the muladd() function in the micro-ecc library into separate mul6464() and add128128() helpers. It seems the check got lost in translation.

Add proper handling for this boundary by accounting for the carry from the lower addition.(CVE-2026-64313)

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

isofs: bound Rock Ridge symlink components to the SL record

getsymlinkchunk() and the SL handling in parserockridgeinodeinternal() walk the variable-length components of a Rock Ridge "SL" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and getsymlinkchunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it.

A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; getsymlinkchunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory.

ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAPSYSADMIN - so the record contents are attacker-controlled.

Reject any component that does not fit in the remaining record bytes before using it. In getsymlinkchunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parserockridgeinodeinternal() stop the inode-size walk.(CVE-2026-64317)

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

nvmet-auth: validate reply message payload bounds against transfer length

nvmetauthreply() accesses the variable-length rval[] array using attacker-controlled hl (hash length) and dhvlen (DH value length) fields without verifying they fit within the allocated buffer of tl bytes.

A malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a small transfer length but large hl/dhvlen values, causing out-of-bounds heap reads when the target processes the DH public key (rval + 2*hl) or performs the host response memcmp.

With DH authentication configured, the OOB pointer is passed directly to sginitone() and read by cryptokppcomputesharedsecret(), reaching up to 526 bytes past the buffer. This is exploitable pre-authentication.

Add bounds validation ensuring sizeof(data) + 2hl + dhvlen <= tl before any access to the variable-length fields.

Discovered by Atuin - Automated Vulnerability Discovery Engine.(CVE-2026-64319)

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

nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page

nvmetexecutediscgetlogpage() validates only the dword alignment of the host-supplied Log Page Offset (lpo). The 64-bit offset is then added to a small kzalloc'd buffer that holds the discovery log page and the result is passed straight to nvmetcopytosgl(), which memcpy()s data_len bytes out to the host with no source-side bound check:

u64 offset      = nvmet_get_log_page_offset(req->cmd);  /* 64-bit host */
size_t data_len = nvmet_get_log_page_len(req->cmd);     /* 32-bit host */
...
if (offset & 0x3) { ... }                               /* only check */
...
alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req);
buffer = kzalloc(alloc_len, GFP_KERNEL);
...
status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);

The Discovery controller is unauthenticated -- nvmethostallowed() returns true unconditionally for the discovery subsystem -- so the call is reachable pre-authentication by any TCP/RDMA/FC peer that can reach the nvmet target. With a discovery log page of ~1 KiB, an attacker requesting up to 4 KiB starting at offset == alloclen reads the next slab page out and gets its content returned over the fabric (an empirical run on a default nvmet-tcp loopback target leaked 81 canonical kernel pointers in one Get Log Page response). Pointing the offset at unmapped kernel memory faults the in-kernel memcpy and crashes (or panics, on panicon_oops=1) the target host instead.

The attacker-controlled source-side offset pattern "nvmetcopytosgl(req, 0, buffer + ATTACKEROFFSET, ...)" is unique to nvmetexecutediscgetlog_page in the entire nvmet codebase: every other Get Log Page handler in admin-cmd.c either ignores lpo (and silently starts every response at offset 0) or tracks a local destination offset with a fixed source pointer.

Validate the host-supplied offset against the log page size, cap the copy length to what is actually available, and zero-fill any remainder of the host transfer buffer. The zero-fill matches the existing short-response pattern in nvmetexecutegetlogchanged_ns() (admin-cmd.c) and prevents leaking transport SGL contents when the host asks for more bytes than the log page contains.(CVE-2026-64320)

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

udf: validate sparing table length as an entry count, not a byte count

udfloadsparable_map() accepts a sparing table when

sizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize

is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block. But the table is walked as an array of 8-byte sparingEntry elements:

for (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) {
    struct sparingEntry *entry = &st->mapEntry[i];
    ... entry->origLocation ...
}

in udfgetpblockspar15() and udfrelocateblocks(). A reallocationTableLen of N therefore passes the check whenever sizeof(*st) + N <= blocksize, yet the consumers index sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the block. On a crafted UDF image this is an out-of-bounds read in udfgetpblockspar15(); udfrelocateblocks() additionally feeds the same length to udfupdatetag(), whose crcitut() reads far past the block, and its memmove() through st->mapEntry[] is an out-of-bounds write.

Validate reallocationTableLen as the entry count it is, with struct_size().(CVE-2026-64322)

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

udf: validate VAT header length against the VAT inode size

udfloadvat() takes the virtual partition's start offset straight from the on-disk VAT 2.0 header without checking it against the VAT inode size:

map->s_type_specific.s_virtual.s_start_offset =
    le16_to_cpu(vat20->lengthHeader);
map->s_type_specific.s_virtual.s_num_entries =
    (sbi->s_vat_inode->i_size -
        map->s_type_specific.s_virtual.s_start_offset) >> 2;

lengthHeader is a fully attacker-controlled 16-bit value. If it exceeds the VAT inode size, the snumentries subtraction underflows to a huge count, which defeats the "block > snumentries" bound in udfgetpblock_virt15(); and on the ICB-inline path that function reads

((__le32 *)(iinfo->i_data + s_start_offset))[block]

so a large sstartoffset indexes past the inode's in-ICB data. Mounting a crafted UDF image with a virtual (VAT) partition then triggers an out-of-bounds read.

Reject a VAT whose header length does not leave room for at least one entry within the VAT inode.(CVE-2026-64323)

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

udf: validate free block extents against the partition length

udffreeblocks() checks the logical block number and count against the partition length, but drops the extent offset from that final bound. A crafted extent can pass the guard while logicalBlockNum + offset + count points past the partition, which later indexes past the space bitmap array.

A single ftruncate(2) on a file backed by such an extent reliably panics the kernel. This is a local availability issue. On desktop systems where UDisks/polkit allows the active user to mount removable UDF media without CAPSYSADMIN, an unprivileged local user can supply the crafted filesystem and trigger the panic by truncating a writable file on it. Systems that require root or CAPSYSADMIN to mount the image have a higher prerequisite.

No confidentiality or integrity impact is claimed: the reproduced primitive is an out-of-bounds read of a bitmap pointer slot followed by a kernel panic.

Use the already computed logicalBlockNum + offset + count value for the partition length check. Also make loadblockbitmap() reject an out-of-range block group before indexing sblockbitmap[], so corrupted callers cannot walk past the flexible array.(CVE-2026-64324)

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 devmapenqueue_clone().

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

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

HID: multitouch: fix out-of-bounds bit access on mtioflags

mtioflags is a single unsigned long, but mtprocessslot(), mtreleasependingpalms() and mtreleasecontacts() use it as a per-slot bitmap indexed by the slot number. That slot number is only bounded by td->maxcontacts, which is taken from the device's ContactCountMaximum feature report and can be up to 255, not by BITSPER_LONG.

As a result, a multitouch device that advertises a large contact count makes setbit()/clearbit() operate past the mtioflags word and corrupt the adjacent members of struct mtdevice. The sticky-fingers release timer is the easiest way to reach this. mtrelease_contacts() runs

for (i = 0; i < mt->num_slots; i++)
    clear_bit(i, &td->mt_io_flags);

with numslots == maxcontacts. For maxcontacts around 250 the loop clears the bits that overlap td->applications.next, zeroing that list head, and the listforeachentry() that immediately follows then dereferences NULL. The kernel panics from timer (softirq) context. On a KASAN build this shows up as a general protection fault in mtreleasecontacts() with a null-ptr-deref at offset 0x58, which is offsetof(struct mtapplication, numreceived).

The state is reachable from an untrusted USB or Bluetooth HID multitouch device; no local privileges are required.

Store the per-slot active state in a separately allocated bitmap sized for maxcontacts, the same pattern already used for pendingpalmslots, and keep only MTIOFLAGSRUNNING in mtioflags. The two "mtioflags & MTIOSLOTSMASK" arming checks become bitmapempty(td->activeslots, td->maxcontacts).

Move MTIOFLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the same commit to leave the low byte for the slot bits; with the slot bits gone it fits in bit 0 again, which also keeps it within the unsigned long on 32-bit.(CVE-2026-64364)

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

sched/rt: Have RTPUSHIPI be default off for non PREEMPT_RT

RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead.

Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task.

This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow.

The solution to that was to create an RTPUSHIPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again.

The RTPUSHIPI solved the latency problem with PREEMPTRT but could cause a new issue with non PREEMPTRT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT.

If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it.

A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed.

When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU.

As RTPUSHIPI was created to help PREEMPTRT, make it default off if PREEMPTRT is not enabled.(CVE-2026-64374)

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

writeback: fix race between cgroupwritebackumount() and inodeswitchwbs()

When a container exits, the following BUG_ON() is occasionally triggered:

================================================================== VFS: Busy inodes after unmount of sdb (ext4) ------------[ cut here ]------------ kernel BUG at fs/super.c:695! CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1 pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : genericshutdownsuper+0xf0/0x100 lr : genericshutdownsuper+0xf0/0x100 Call trace: genericshutdownsuper+0xf0/0x100 killblocksuper+0x20/0x48 ext4killsb+0x28/0x60 deactivatelockedsuper+0x54/0x130 deactivatesuper+0x84/0xa0 cleanupmnt+0xa4/0x140 _cleanupmnt+0x18/0x28 taskworkrun+0x78/0xe0

donotifyresume+0x204/0x240

The root cause is a race between cgroupwritebackumount() and inodeswitchwbs()/cleanupofflinecgwb(). There is a window between inodepreparewbsswitch() returning true and the subsequent wbqueue_isw() call. Following is the process that triggers the issue:

  CPU A (umount)           |          CPU B (writeback)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ inodeswitchwbs/cleanupofflinecgwb atomicinc(&iswnrinflight) inodepreparewbsswitch -> passes SBACTIVE check _iget(inode) genericshutdownsuper sb->sflags &= ~SBACTIVE cgroupwritebackumount(sb) smpmb() atomicread(&iswnrinflight) rcubarrier() -> no pending RCU callbacks flushworkqueue(iswwq) -> nothing queued, returns evictinodes(sb) -> Inode skipped as isw still holds a ref. sop->putsuper(sb) /* destroys percpu counters */ -> VFS: Busy inodes after unmount! wbqueueisw() queuework(iswwq, ...) /* later in work function */ inodeswitchwbsworkfn processinodeswitchwbs iput() -> evict percpucounterdec() // UAF!

Fix this by extending the RCU read-side critical section in inodeswitchwbs() and cleanupofflinecgwb() to cover from inodepreparewbsswitch() through wbqueueisw(). Since there is no sleep in this window, rcureadlock() can be used. Then add a synchronizercu() in cgroupwritebackumount() before the existing rcubarrier(), so that all in-flight switchers that have passed the SBACTIVE check have completed queuework() before flushworkqueue() is called.

The existing rcubarrier() is intentionally retained so this fix can be backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that still queue switches via queuercuwork(). It is a no-op on current mainline (since commit e1b849cfa6b6 ("writeback: Avoid contention on wb->listlock when switching inodes")) and is removed in a follow-up patch.(CVE-2026-64378)

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

smb: client: mask server-provided mode to 07777 in modefromsid

When modefromsid is active, parsedacl() applies the server-provided subauth[2] value from the NFS mode SID to cf_mode without masking to 07777. Apply the correct masking, same as in the read path.(CVE-2026-64379)

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

smb: client: harden POSIX SID length parsing

posixinfosid_size() reads sid[1] to obtain the subauthority count, but its existing boundary check still accepts buffers with only one remaining byte. Require two bytes before reading sid[1] so all client paths that reuse the helper reject truncated POSIX SIDs safely.(CVE-2026-64380)

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

smb: client: fix double-free in SMB2_open() replay

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2openinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64382)

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

smb: client: fix double-free in SMB2_flush() replay

SMB2flush() keeps its response buffer bookkeeping across replay attempts. If a replayable flush response is received and the retry then fails before cifssendrecv() stores a replacement response, flushexit will free the stale response pointer a second time.

Reinitialize respbuftype and rspiov at the top of the replay loop so cleanup only acts on response state produced by the current attempt. This fixes a double-free without changing replay handling for successful requests.(CVE-2026-64383)

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

smb: client: fix change notify replay double-free

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2notifyinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64384)

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

smb: client: fix double-free in SMB2_ioctl() replay

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2ioctlinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64385)

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

smb: client: fix query_info() replay double-free

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2queryinfo_init() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64386)

In the Linux kernel, an out-of-bounds read vulnerability exists in the SMB client. smb2checkmessage() has a long-standing quirk that accepts a response whose calculated length is one byte larger than the bytes actually received ("server can return one byte more due to implied bcc[0]"). This was introduced to accommodate servers that omit the trailing bcc[0] overlap byte when no data area is present. However, the exemption is applied unconditionally, regardless of whether the command actually carries a data area (hassmb2dataarea[]). When a response with a data area is subject to the +1 exemption, the reported data can extend one byte beyond the bytes actually received, causing the subsequent decoder to read past the end of the receive buffer. This is reachable during NEGOTIATE and SESSIONSETUP, before the session is established. The resulting out-of-bounds reads are visible under KASAN when mounting against a non-conforming server, affecting both the SPNEGO/negTokenInit and the NTLMSSP challenge decoders.(CVE-2026-64448)

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

hwrng: virtio: clamp device-reported used.len at copy_data()

randomrecvdone() stores the device-reported used.len directly into vi->dataavail. copydata() then indexes vi->data[] using vi->dataidx (advanced by previous copydata() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi->data) (SMPCACHEBYTES bytes, typically 32 or 64).

A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi->data), steering the memcpy() past the end of the inline array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes those bytes into the guest RNG, and guest root can also observe them directly via /dev/hwrng.

Concrete impact is inside the guest:

• Memory-safety / hardening: any virtio-rng backend that over-reports used.len causes the driver to read past vi->data into unrelated slab contents. hwrng_fillfn() is a kernel thread that runs as soon as the device is probed; no guest userspace interaction is required to first-trigger the OOB.

• Cross-boundary leak (confidential-compute threat model): a malicious hypervisor cooperating with a malicious or compromised guest root userspace can use /dev/hwrng as a leak channel for guest-kernel heap data. The host sets a large used.len, guest root reads /dev/hwrng, and the returned bytes contain guest kernel slab contents that were adjacent to vi->data. In practice, confidential-compute guests (SEV-SNP, TDX) usually disable virtio-rng entirely, so this path is narrow, but the fix is still worth carrying because the underlying memory-safety bug contaminates the guest RNG on any host.

KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend has been patched to report used.len = 0x10000:

BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52 Call Trace: __asanmemcpy+0x23/0x60 virtioread+0x394/0x5d0 hwrngfillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Allocated by task 1: probecommon+0xa5/0x660 virtiodevprobe+0x549/0xbc0 The buggy address belongs to the object at ffff88800ae0b800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes to the right of allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20)

Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened usb9pfsrxcomplete() against unchecked device-reported length in the USB 9p transport.

With the clamp at point of use and arrayindexnospec() in place, the same harness boots cleanly: copydata() returns zero for the bogus report, the device-supplied bytes after dataidx are discarded, and the driver issues a fresh request.(CVE-2026-64456)

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

ALSA: hda/cs35l41: Fix firmware load work teardown

cs35l41hda creates ALSA controls whose private data points at the cs35l41hda object. The firmware load control can also queue fwloadwork.

Those controls are not removed on component unbind, and device remove only cancels fwloadwork through cs35l41removedsp(). That helper is skipped when haloinitialized is false. With firmwareautostart disabled, a firmware load can be requested before the DSP has been initialized. If the component or device is removed before the queued work runs, the worker can run after teardown and dereference driver state that is no longer valid.

Track the created controls and remove them on unbind so no new control callback can reach the driver data or queue more work. Then cancel fwloadwork to drain any request that was already queued. Also cancel the work unconditionally during device remove before runtime PM teardown.(CVE-2026-64481)

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

iio: event: Fix event FIFO reset race

iio_event_getfd() creates the event file descriptor with anon_inode_getfd(), which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller.

The IIO code resets the event FIFO after anon_inode_getfd() has returned, but before IIO_GET_EVENT_FD_IOCTL has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a read() on it as soon as the fd has been installed.

This means the kfifo_to_user() in iio_event_chrdev_read() can run in parallel with the kfifo_reset_out() in iio_event_getfd().

The kfifo documentation says that kfifo_reset_out() is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as kfifo_reset().

If that happens, kfifo_to_user() can advance the FIFO out index based on state from before the reset, after the reset has already moved the out index to the current in index. That can leave the FIFO with an out index past the in index. A later read() can then see an underflowed FIFO length and copy more data than the event FIFO buffer contains. This can result in an out-of-bounds read and leak adjacent kernel memory to userspace.

Move the FIFO reset before anon_inode_getfd(). At that point the event fd is marked busy, but the new fd has not been installed yet, so userspace cannot access it while the FIFO is reset.(CVE-2026-64496)

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

net: openvswitch: reject oversized nested action attrs

Open vSwitch stores generated flow actions as nlattrs, whose nlalen field is u16. Commit a1e64addf3ff ("net: openvswitch: remove misbehaving actions length check") allowed the total swflowactions stream to grow beyond 64 KiB, which is valid, but also removed the last guard preventing a generated nested action attribute from exceeding U16MAX.

An oversized generated container can thus be closed with a truncated nla_len. A later dump or teardown then walks a structurally different stream than the one that was validated. In particular, an oversized nested CLONE/CT action may cause subsequent bytes in the generated stream to be interpreted as independent actions.

Keep the larger total-action-stream behavior, but make nested action close reject generated containers that do not fit in nlalen, and return the error through all callers. For recursive SAMPLE, CLONE, DECTTL, and CHECKPKTLEN builders, trim resource-owning action-list tails in reverse construction order before discarding failed wrappers, so resources copied into the rejected tails are released before the wrappers are removed.

Most failed outer wrappers are discarded by truncating actionslen after child resources have been released. CHECKPKTLEN also trims its parent after branch resources are gone. SET/TUNNEL close failures unwind their known tundst ownership directly, and SETTOMASKED has no external ownership and truncates on close failure.(CVE-2026-64531)

In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Detach event groups during removeonexec\n\nperfeventremoveonexec() removes events by calling\nperfeventexitevent(). For top-level events, this removes the event from\nthe context with DETACHEXIT only.\n\nThis can leave inconsistent group state when a removed event is a group\nleader and the group contains siblings without removeonexec. If the group\nwas active, the surviving siblings can remain active and attached to the\nremoved leader's sibling list, but are no longer represented by a valid\ngroup leader on the PMU context active lists.\n\nA later close of the removed leader uses DETACHGROUP and can promote the\nstill-active siblings from this stale group state. The next schedule-in can\nthen add an already-linked activelist entry again, corrupting the PMU\ncontext active list.\n\nWith DEBUGLIST enabled, this is caught as a listadd double-add in\nmergeschedin().\n\nFix this by detaching group relationships when removeonexec removes an\nevent. This preserves the existing task-exit and revoke behavior, while\nensuring surviving siblings are ungrouped before the removed event leaves\nthe context.(CVE-2026-64556)

In the Linux kernel, a use-after-free (UAF) vulnerability exists caused by a non-leader exec() race condition in posix-cpu-timers. When systimerdelete() observes the old leader, while dethread() executes switchleader() and releases the old leader, a race condition occurs. Specifically, posixcputimerdel() in systimerdelete() obtains the old leader via pidtask(), while dethread() is executing releasetask(oldleader) and setting oldleader->sighand = NULL. When locktasksighand() returns NULL, systimerdelete() frees the posix timer object. However, if the timer was armed and enqueued in p->signal (a TGID targeted timer is inherited on exec()), runposixcputimers() or other timerqueue add/delete operations will access the freed object's timerqueue node, resulting in a use-after-free. This issue similarly affects posixcputimerset() and posixcputimer_rearm(). The history of this vulnerability goes back to the early days of posix CPU timers implementation.(CVE-2026-64560)

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Check for invalid/obsolete root after making MMU pages available\n\nCheck for a &quot;stale&quot; page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is &quot;fine&quot;, but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages.\n\nNote, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, &quot;KVM: MMU: ignore zapped root pagetables&quot;), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages.\n\nNote #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.(CVE-2026-64561)

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

smb: client: fix double-free in SMB2_close() replay

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2closeinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64597)

In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation. __ipvsgetoutrt() calls skbensurewritable() which may reallocate skb->head, causing the previously obtained IP header pointer to become a dangling pointer, leading to a use-after-free vulnerability.(CVE-2026-68476)

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

ipvs: fix more places with wrong ipv6 transport offsets

Sashiko reports for more incorrect IPv6 transport offsets.

The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers.

Also, provide correct offset of the ICMPV6 header in ipvsouticmpv6() for correct checksum checks when the IPv6 packet has extension headers.(CVE-2026-68477)

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

ipvs: use parsed transport offset in SCTP state lookup

setsctpstate() reads the SCTP chunk header again in order to drive the IPVS SCTP state table. For IPv6 it computes the offset with sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from ipvsfilliphskb(), where ipv6findhdr() has already skipped extension headers and found the real transport header.

This makes the state machine read from the wrong offset for IPv6 SCTP packets that carry extension headers. For example, an INIT packet with an 8-byte destination options header can be scheduled correctly by sctpconnschedule(), but setsctpstate() reads the first byte of the SCTP verification tag as a DATA chunk type. The connection then moves from NONE to ESTABLISHED instead of INIT1, gets the longer established timeout, and updates the active/inactive destination counters incorrectly. This happens even though the SCTP handshake has not completed.

Use the parsed transport offset passed down from ipvsset_state() for the SCTP chunk-header lookup. For IPv4 and IPv6 packets without extension headers this preserves the existing offset.(CVE-2026-72021)

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

ieee802154: admin-gate legacy LLSEC dump operations

In net/ieee802154/netlink.c, the legacy IEEE802154NL family ops table builds the LLSEC dump entries (LLSECLISTKEY, LLSECLISTDEV, LLSECLISTDEVKEY, LLSECLISTSECLEVEL) with IEEE802154DUMP() which sets no .flags, so generic netlink runs them ungated. The modern nl802154 family admin-gates the equivalent reads via NL802154CMDGETSECKEY and friends with .flags = GENLADMINPERM.

Any local uid that can open AFNETLINK / NETLINKGENERIC can resolve the "802.15.4 MAC" family and dump LLSECLISTKEY on any wpan netdev that has an LLSEC key installed; the dump handler writes the raw 16-byte AES-128 key bytes (IEEE802154ATTRLLSECKEYBYTES, copied verbatim from struct ieee802154llseckey.key) into the reply. Recovering the AES key compromises 802.15.4 LLSEC link confidentiality and authenticity, since LLSEC uses CCM* and the same key authenticates and encrypts frames.

Impact: any local uid with no capabilities can read the raw 16-byte AES-128 LLSEC key from the kernel keytable on any wpan netdev that has an administrator-installed LLSEC key, by issuing an LLSECLISTKEY dump on the legacy IEEE802154_NL generic-netlink family.

Introduce IEEE802154DUMPPRIV() mirroring IEEE802154DUMP() but setting .flags = GENLADMINPERM, and use it for the four LLSEC dump entries. LISTPHY and LISTIFACE retain IEEE802154DUMP() because the modern nl802154 family exposes their equivalents to unprivileged readers by design (NL802154CMDGETWPANPHY and NL802154CMDGET_INTERFACE carry "can be retrieved by unprivileged users" annotations).(CVE-2026-72049)

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

net: ip6gre: require CAPNET_ADMIN in the device netns for changelink

ip6grechangelink() and ip6erspanchangelink() operate on at most two netns, devnet(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAPNETADMIN only against devnet(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.

Gate both ops on rtnldevlinknetcapable() at their top, before any attribute is parsed.(CVE-2026-72052)

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

net: ipip: require CAPNETADMIN in the device netns for changelink

ipipchangelink() operates on at most two netns, devnet(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAPNETADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.

Gate ipipchangelink() on rtnldevlinknet_capable() at its top, before any attribute is parsed.(CVE-2026-72053)

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

net: ipvti: require CAPNET_ADMIN in the device netns for changelink

vtichangelink() operates on at most two netns, devnet(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAPNETADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.

Gate vtichangelink() on rtnldevlinknet_capable() at its top, before any attribute is parsed.(CVE-2026-72054)

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

net: sit: require CAPNETADMIN in the device netns for changelink

ipip6changelink() operates on at most two netns, devnet(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAPNETADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.

Gate ipip6changelink() on rtnldevlinknet_capable() at its top, before any attribute is parsed. sit was the one tunnel type not covered by the recent series that added this check to the other changelink() handlers.(CVE-2026-72061)

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

net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete

When an offloaded MACsec RX SC is deleted, macsecdelrxscctx() freed the per-SC metadatadst with metadatadstfree(), which kfree()s the object unconditionally and ignores the dst reference count. The RX datapath in mlx5emacsecoffloadhandlerxskb() looks up the SC under rcureadlock() via xaload(), takes a reference with dsthold() and attaches the dst to the skb with skbdstset(). A reader that already obtained the rxsc pointer can race with the delete path and operate on freed memory.

Fix the owner side by dropping the reference with dstrelease() instead of freeing unconditionally, and convert the RX datapath to dsthold_safe() so a reader racing the SC delete cannot attach a dst whose last reference was just dropped; only attach it when a reference was actually taken.

mlx5emacsecaddrxsc() also published scxarrayelement via xaalloc() before rxsc->mddst was allocated and initialised, so a datapath reader that looked the SC up by fsid could observe rxsc with mddst still NULL or, on weakly-ordered architectures, a non-NULL mddst pointer whose contents were not yet visible. NULL-check the xaload() result and mddst on the datapath, and reorder addrxsc() so the xaalloc() publish happens only after mddst is fully initialised; the xarray RCU publish then pairs with the rcureadlock()/xaload() in the datapath.

Note: macsecdelrxscctx() also kfree()s rxsc->scxarrayelement without an RCU grace period while the same datapath reads it under rcureadlock(); that is a separate pre-existing issue left to a follow-up patch.

Found by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-72072)

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

dm-log: fix a bitset_size overflow on 32bit machines

Commit c20e36b7631d ("dm log: fix out-of-bounds write due to regioncount overflow") made sure that regioncount could fit in an unsigned int. But the bitmap memory isn't allocated based on regioncount. It uses bitsetsize (a sizet variable). The first step of calculating bitsetsize is to set it to regioncount, rounded up to a multiple of BITSPERLONG. If regionsize is less than BITSPERLONG smaller than UINTMAX, it will get rounded up to 2^32. On a 32bit architecture, this will make bitsetsize wrap around to 0 and fail, despite region_count being valid.

Since bitsetsize gets divided by 8, it can hold any valid regioncount. It just needs a special case to handle the rollover. If it is 0, the value rolled over, and bitset size should be set to the number of bytes needed to hold 2^32 bits.(CVE-2026-72105)

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

bpf,fork: wipe ->bpf_storage before bailouts that access it

Currently, copyprocess() can bail out to freetask() before p->bpfstorage has been initialized, with this call graph (shown here for the !CONFIGMEMCG case):

copyprocess duptaskstruct archduptaskstruct [copies the entire taskstruct, including ->bpfstorage member] [RLIMITNPROC check fails] delayedfreetask freetask bpftaskstoragefree rcudereference(task->bpfstorage) bpflocalstoragedestroy

In this case, the nascent task's ->bpfstorage member that bpflocalstoragedestroy() operates on is a plain copy of the parent's ->bpf_storage pointer, not a real initialized pointer. This leads to badness (kernel hangs, UAF).

This is reachable as long as the process calling fork() has been inserted into a task storage map.(CVE-2026-72110)

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

nvmet-rdma: handle inline data with a nonzero offset

nvmetrdmauseinlinesg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inlinedatasize, but the mapping still assumes the data begins in the first inline page:

sg->offset = off;
sg->length = min_t(int, len, PAGE_SIZE - off);

When a port is configured with inlinedatasize > PAGESIZE (settable up to max(SZ16K, PAGESIZE)), an offset in (PAGESIZE, inlinedatasize] makes "PAGESIZE - off" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. numpages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist.

Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from pageoff + len. Because the request scatterlist may now start at inlinesg[pageidx] rather than inlinesg[0], generalize the inline-SGL identity test in nvmetrdmareleasersp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmetreqfreesgls() frees an inline page (and warns in freelargekmalloc()).(CVE-2026-72129)

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

tpm: Make the TPM character devices non-seekable

The TPM character devices expose a sequential command/response interface, but their open handlers leave FMODEPREAD and FMODEPWRITE enabled.

After a command leaves a response pending, pread(fd, buf, 16, 0x1400) passes 0x1400 as *off to tpmcommonread(). The transfer length is bounded by responselength, but the offset is used unchecked when forming databuffer + *off. A sufficiently large offset therefore causes an out-of-bounds heap read through copytouser() and, if the copy succeeds, an out-of-bounds zero-write through the following memset().

Positional I/O does not provide coherent semantics for this interface. An arbitrary pread offset cannot represent how much of a response has been consumed sequentially. The write callback always stores a command at the start of databuffer, while pwrite() does not update file->fpos and can leave the sequential read cursor stale.

Call nonseekableopen() from both open handlers. This removes FMODEPREAD and FMODEPWRITE, causing positional reads and writes to fail with -ESPIPE before reaching the TPM callbacks, and explicitly marks the files non-seekable. Normal read() and write() continue to use the existing sequential fpos cursor, leaving the response state machine unchanged.

Tested on Linux 6.12 with KASAN and a swtpm TPM2 device:

• sequential partial reads returned the complete response
• pread() and preadv() with offset 0x1400 returned -ESPIPE
• pwrite() and pwritev() with offset zero returned -ESPIPE
• the pending response remained intact after the rejected operations
• a subsequent normal command/response cycle completed normally
• no KASAN report was produced.(CVE-2026-72135)

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

xfrm: xfrminterface: require CAPNET_ADMIN in the device netns for changelink

xfrmichangelink() operates on at most two netns, devnet(dev) and the interface link netns xi->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAPNETADMIN only against dev_net(dev), so a caller privileged there but not in xi->net can rewrite an interface that lives in xi->net.

Gate xfrmichangelink() on rtnldevlinknet_capable() at its top, before any attribute is parsed.(CVE-2026-72136)

In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Fix frags[] overflow by bounding framecount. tbnetpoll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment. A packet of framecount frames therefore ends up with framecount - 1 fragments. tbnetcheckframe() only bounds the peer supplied framecount to TBNETRINGSIZE / 4 (64), which is far above MAXSKBFRAGS (17 by default). A peer that sends a packet of 19 or more small frames pushes nrfrags past MAXSKBFRAGS, so skbaddrxfrag() writes past skbshinfo()->frags[] and corrupts memory after the shared info.(CVE-2026-72157)

In the Linux kernel, the following vulnerability has been resolved: mm/mminit: fix uninitialized struct pages for ZONEDEVICE. If DAX memory is hotplugged into an unoccupied subsection of an early section, sectionactivate() reuses the unoptimized boot memmap. However, compoundnr_pages() still assumes that vmemmap optimization is in effect and initializes only the reduced number of struct pages. As a result, the remaining tail struct pages are left uninitialized, which can later lead to unexpected behavior or crashes. Fix this by treating early sections as unoptimized when calculating how many struct pages to initialize.(CVE-2026-72172)

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

SUNRPC: Bound-check xdrbufto_bvec() stores before writing

xdrbuftobvec() writes a biovec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it.

rqbvec, the array passed by nfsdvfswrite(), is allocated to exactly rqmaxpages entries with no slack. The OOB store can land in adjacent slab memory; the bvlen and bvoffset fields written there are derived from client-supplied RPC payload sizes.

Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.(CVE-2026-72217)

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

sunrpc: wait for in-flight TLS handshake callback when cancel loses race

When waitforcompletioninterruptibletimeout() in svctcphandshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tlshandshakecancel() then returns false, handshakecomplete() has won the cancellation race: it has set HANDSHAKEFREQCOMPLETED and is about to invoke svctcphandshakedone(), but the callback's side effects on xptflags and on svsk->skhandshakedone have not yet committed.

The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result.

If the callback has executed setbit(XPTTLSSESSION) but not yet clearbit(XPTHANDSHAKE), svctcphandshake() sees a session, enqueues the transport, and returns. svcxprtreceived() then clears XPTBUSY, a worker thread picks the transport up, the dispatcher in svchandlexprt() observes XPTHANDSHAKE still set, and xpohandshake is invoked a second time. That svctcphandshake() calls initcompletion(&svsk->skhandshakedone) while the original callback concurrently calls completeall() on it, corrupting the embedded swait_queue.

If the callback has set HANDSHAKEFREQCOMPLETED but not yet entered svctcphandshakedone(), svctcphandshake() reads XPTTLSSESSION as clear and tears the connection down even though the handshake is about to succeed.

Wait for the callback to commit before inspecting xptflags. The completion is guaranteed to fire because handshakecomplete() invokes svctcphandshakedone() unconditionally once it has set HANDSHAKEFREQCOMPLETED.(CVE-2026-72221)

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

sunrpc: pin svc_xprt across the asynchronous TLS handshake callback

svctcphandshake() stores the raw svcxprt pointer in tlshandshakeargs.tadata and submits the request through tlsserverhellox509(). The handshake core takes only sockhold(req->hrsk); nothing references the embedding struct svcsock that svctcphandshakedone() reaches via containerof().

Two close races leave the in-flight callback writing through a freed svcsock. svcsockfree() calls tlshandshakecancel() and discards its return value: a false return means handshakecomplete() has already set HANDSHAKEFREQCOMPLETED but hpdone() may not have finished, yet svcsockfree() proceeds to kfree(svsk). The cancel-loser fall-through inside svctcphandshake() itself produces the same window: when waitforcompletioninterruptibletimeout() returns <= 0 (timeout or signal) and tlshandshakecancel() returns false, the function does not drain, returns, and svchandlexprt() calls svcxprtreceived(), which clears XPTBUSY and can drop the last reference. A concurrent close then runs svcsockfree() while svctcphandshakedone() is still updating xptflags and walking svsk->skhandshake_done.

The corruption surfaces as setbit/clearbit RMW into the freed xptflags slab slot and as completeall() walking and writing the freed waitqueueheadt list embedded in skhandshakedone -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVCHANDSHAKE_TO expiry.

Take svcxprtget(xprt) immediately before tlsserverhellox509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tlsserverhellox509() and a successful tlshandshakecancel() -- and at the tail of svctcphandshakedone() after completeall().

cel: rewrote commit message to describe the actual change

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

batman-adv: retrieve ethhdr after potential skb realloc on RX

pskbmaypull() in batadvinterfacerx() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free.

This was done correctly for the VLAN header but missed for the ethernet header which is later used for the TT and AP isolation handling.(CVE-2026-72235)

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

KVM: Move kvmiobusgetdev() locking responsibilities to callers

kvmiobusgetdev() returns a device that is only matched by the address, and nothing else. This can cause a lifetime issue if the matched device is not the expected type, as by the time the caller can introspect the object, it might be gone (the srcu lock having been dropped).

Given that there is only a single user of this helper, the simplest option is to move the locking responsibility to the caller, which can keep the srcu lock held for as long as it wants.

Note that this aligns with other kvmiobus*() helpers, which already require the srcu lock to be held by the callers.(CVE-2026-72282)

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check. smb2ioctlqueryinfo() validates the PASSTHRUFSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.inputbufferlength directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copytouser() then reads from io_rsp + OutputOffset, outside the response buffer, leading to an out-of-bounds read.(CVE-2026-72310)

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

dm era: fix NULL pointer dereference in metadata_open()

metadataopen() returns NULL when kzallocobj() fails, but the caller eractr() only checks ISERR(md). Since IS_ERR(NULL) returns false, the NULL pointer is treated as a valid result and later assigned to era->md, leading to a NULL pointer dereference when the metadata is accessed.

Fix this by returning ERRPTR(-ENOMEM) on allocation failure, consistent with dm-cache-metadata.c, dm-thin-metadata.c, and dm-clone-metadata.c which all use ERRPTR(-ENOMEM) for the same pattern.(CVE-2026-72316)

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

SUNRPC: pin upper rpcclnt across the TLS connectworker

The TLS connect path has a use-after-free: nothing pins the upper rpcclnt across the delayed connectworker. xsconnect() stores task->tkclient in sockxprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xstcptlssetupsocket(), which reads several fields out of the saved pointer (cltimeout, clprogram, clprog, clvers, clcred, clstats) to construct the args for the inner handshake rpcclnt.

The xprt does not reference the rpcclnt; the rpcclnt references the xprt. xsdestroy() does cancel the connectworker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpcclnt releases its clxprt reference in rpcfreeclientwork(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpcshutdownclient(), and the upper rpcclnt is freed before the queued connectworker fires. xstcptlssetupsocket() then dereferences the freed clnt, producing the refcountt underflow Michael Nemanov reported.

Take a reference on the upper rpcclnt in xsconnect() for TLS transports via a new rpcholdclient() helper, and drop it in the connectworker's exit path with rpcreleaseclient(). The xprtlockconnect() / xprtunlockconnect() pairing already serialises xsconnect() with xstcptlssetupsocket(), so the take and release are balanced one-for-one.

The non-TLS connect worker (xstcpsetupsocket) never reads sockxprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.(CVE-2026-72317)

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

cifs: validate DFS referral string offsets

parsedfsreferrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server.

Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative maxlen is then passed to cifsstrndupfromutf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds.

Validate each string offset before deriving the string pointer.(CVE-2026-72318)

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

ipvs: ensure inner headers in ICMP errors are in headroom

Sashiko points out that after stripping the outer headers with pskbpull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4updatepmtu(), icmpsend() and IPVSDBG().

Also, add more checks for the length of the inner headers.(CVE-2026-72319)

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

net/tls: Consume empty data records in tlsswread_sock()

A peer may send a zero-length TLS applicationdata record; TLS 1.3 explicitly permits these as a traffic-analysis countermeasure (RFC 8446, Section 5.1). After decryption such a record has fulllen == 0. tlsswreadsock() hands it to the readactor, which has no payload to consume and returns zero. The loop treats a zero return as backpressure (used <= 0), requeues the skb at the head of rxlist, and stops. rxlist is serviced head-first on the next call, so the empty record is dequeued, fails the same way, and is requeued again; every later record on the connection is blocked behind it.

tlsswrecvmsg() does not stall on this: a zero-length data record copies nothing and falls through to consumeskb(). Mirror that in the readsock() path by recognizing an empty data record before the actor runs, consuming it, and continuing.(CVE-2026-72330)

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

qede: fix off-by-one in BD ring consumption on build_skb failure

qederxbuildskb() and qedetparxbuildskb() do not check for a NULL return from qedebuild_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption.

Commit 4e910dbe3650 ("qede: confirm skb is allocated before using") added a NULL check inside qedebuildskb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable.

Fix this by adding NULL checks for the return value of qedebuildskb() in both qederxbuildskb() and qedetparxbuild_skb(), returning NULL immediately before any BD ring manipulation.(CVE-2026-72339)

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

net/mlx5e: Fix HV VHCA stats agent registration race

mlx5ehvvhcastatscreate() registers the stats agent through mlx5hvvhcaagentcreate(). The helper publishes the agent in hvvhca->agents[type] under agentslock and immediately schedules an asynchronous control invalidation on the HV VHCA workqueue before returning to mlx5e.

The asynchronous invalidation invokes the control agent's invalidate callback, which reads the hypervisor control block and forwards the command to mlx5ehvvhcastatscontrol(). That callback may either:

• call canceldelayedworksync(&priv->statsagent.work), or
• call queuedelayedwork(priv->wq, &sagent->work, sagent->delay).

However, the delayedwork and priv->statsagent.agent are only initialized after mlx5hvvhcaagentcreate() returns to mlx5e:

agent = mlx5_hv_vhca_agent_create(...);   /* publish + invalidate */
...
priv->stats_agent.agent = agent;          /* too late */
INIT_DELAYED_WORK(&priv->stats_agent.work, ...); /* too late */

If the asynchronous control path runs before the two assignments above, it can:

• Operate on an uninitialized delayedwork whose timer.function is NULL. queuedelayedwork() calls addtimer() unconditionally, so when the timer expires the timer softirq invokes a NULL function pointer.
• Re-initialize the timer later through INITDELAYEDWORK() while the timer is already enqueued in the timer wheel, corrupting the hlist (entry.pprev cleared while the previous bucket node still points at this entry).
• When the worker eventually runs, mlx5ehvvhcastatswork() reads sagent->agent (NULL) and dereferences it inside mlx5hvvhcaagentwrite().

Fix this by:

• Initializing priv->statsagent.work before invoking mlx5hvvhcaagent_create(), so the work is always in a valid state when the control callback observes it.
• Adding a struct mlx5hvvhcaagent **ctxupdate out-parameter to mlx5hvvhcaagentcreate(). The helper writes the agent pointer to *ctxupdate before publishing into hvvhca->agents[] and triggering the agentsupdate flow, so any callback subsequently invoked from that flow already sees a valid priv->statsagent.agent. This avoids having the control callback participate in agent initialization.

While at it, access priv->statsagent.agent with READONCE()/WRITEONCE() for the cross-CPU access with the worker, and clear priv->statsagent.buf on the agent_create() failure path.(CVE-2026-72342)

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

seg6: validate SRH length before reading fixed fields

seg6validatesrh() reads fixed SRH fields such as srh->type and srh->hdrlen before checking that the supplied length covers the fixed struct ipv6srhdr fields.

The BPF SEG6 encap path reaches this with a BPF program-supplied pointer and length: bpflwtpushencap() and the SEG6 local BPF ENDB6 and ENDB6ENCAP actions call bpfpushseg6encap(), which forwards the length to seg6validate_srh() with no minimum-size guard. A 2-byte SEG6 encap header can therefore make the validator read srh->type at offset 2 beyond the caller-supplied buffer.

Reject lengths shorter than the fixed SRH at the top of seg6validatesrh(), before any field is read. This fixes the BPF helper path and keeps the common validator robust.(CVE-2026-72400)

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

ice: fix FDIR CTRL VSI resource leak in iceresetall_vfs()

Resetting all VFs causes resource leak on VFs with FDIR filters enabled as CTRL VSIs are only invalidated and not freed. Fix by using icevfctrlvsirelease() instead of icevfctrlinvalidatevsi() which aligns behavior with the iceresetvf() function.

Reproduction: echo 1 > /sys/class/net/$pf/device/sriov_numvfs ethtool -N $vf flow-type ether proto 0x9000 action 0 echo 1 > /sys/class/net/$pf/device/reset(CVE-2026-72425)

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

xfrm: validate selector family and prefixlen during match

syzbot reported a shift-out-of-bounds in xfrmselectormatch() due to AFUNSPEC selector with large prefixlen (e.g. 128) matched against IPv4 flow (when XFRMSTATEAFUNSPEC is set).

Fix this by:

• Rejecting mismatched families in xfrmselectormatch.
• Returning false in addr4_match if prefixlen > 32.
• Returning false in addr_match if prefixlen > 128 (prevents overflow).(CVE-2026-72450)

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

apparmor: aalabelalloc use aalabelfree on alloc failure

aalabelalloc() allocates a secid before allocating or taking the label proxy. If the later proxy step fails, the error path only freed the label memory, leaking any resources initialized by aalabelinit().

Use aalabelfree() on the failure path so partially initialized labels release their secid and other label resources before the backing memory is freed.(CVE-2026-72459)

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

apparmor: check label build before nonewprivs test

aachangeprofile() builds a replacement label with fnlabelbuildinscope() before the nonewprivs subset check. The build helper can fail and return NULL or an ERRPTR, but the result was passed to aalabelisunconfinedsubset() before the existing ISERRORNULL() check.

Reuse the existing target-label build failure handling immediately after the build. This preserves the current audit handling while preventing the subset helper from dereferencing an invalid label.(CVE-2026-72460)

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

xprtrdma: Repost Receive buffers for malformed replies

rpcrdmawcreceive() decrements the transport's Receive count for every completion before it dispatches a successful Receive to rpcrdmareplyhandler(). The handler must post a replacement Receive WR before returning unless ownership of the rep has moved elsewhere, as on the backchannel path.

Commit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") moved the Receive refill out of rpcrdmawcreceive(), where it had run ahead of every reply, into rpcrdmareplyhandler() so that the responder's credit grant could be parsed before reposting. The bad-version and short-reply exits never reach that refill: they recycle the rep and return without calling rpcrdmapostrecvs().

A remote peer can therefore drain the client's posted Receive queue by sending a sustained stream of replies that are shorter than the fixed transport header or that carry an unrecognized RPC/RDMA version. Each such reply consumes one posted Receive without replacing it. Once the queue empties, the peer's next Send finds no posted Receive and the transport stalls until reconnect.

Route both malformed-reply exits through the shared repost tail after recycling the rep, refilling against buf->rbcredits, the most recent accepted credit grant. Neither exit updates the congestion window, so RPCs admitted under the previous grant remain in flight awaiting replies. A smaller refill target would let a stream of malformed replies ratchet the posted Receive count down to the batch floor while the congestion window still admits rbcredits RPCs; a burst of valid replies to those RPCs could then overrun the posted Receives, and because the client connects with rnrretrycount of zero, a single RNR NAK terminates the connection. Refilling against rbcredits also restores the target that applied to malformed replies before commit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") when rpcrdmapostrecvs() computed it from rbcredits internally. rb_credits is at least one from connection establishment onward, so the repost path always keeps Receives posted.(CVE-2026-72464)

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

xprtrdma: Sanitize the reply credit grant after parsing

The outnorqst exit in rpcrdmareplyhandler() branches away before the credit clamp, so a reply that matches no pending request reaches outpost carrying the raw credit value parsed from the wire. rpcrdmapostrecvs() does not bound its @needed argument: the refill loop allocates and chains Receive WRs until the count is satisfied or allocation fails. A peer that sends a well-formed reply carrying an unknown XID and an inflated credit grant therefore drives rep allocation and Receive posting past remaxrequests on every such reply.

Move the clamp to immediately after the credit field is parsed, ahead of the first branch that can reach out_post, so every later consumer sees a sanitized value. The cwnd update stays on the matched-request path.(CVE-2026-72465)

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

xprtrdma: Fix bcall rep leak and unbounded peek

rpcrdmaisbcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue.

First, the speculative peek

p = xdr_inline_decode(xdr, 0);
/* five p++ reads follow */

asks xdrinlinedecode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call.

Second, after the post-peek

p = xdr_inline_decode(xdr, 3 * sizeof(*p));
if (unlikely(!p))
        return true;

the short-header arm returns true without calling rpcrdmabcreceive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path:

rpcrdma_reply_handler()
  if (rpcrdma_is_bcall(r_xprt, rep))
          return;        /* bare return, skips out_post */
  ...
out_post:
  rpcrdma_post_recvs(r_xprt, credits + ...);

Because rpcrdmabcreceivecall() never ran, no one took rep, but rpcrdmareplyhandler still bare-returns past rpcrdmarepput() and rpcrdmapostrecvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rballreps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches outpost and rpcrdmapostrecvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs.

Fix by consulting xdr->end after the zero-length peek so the five _be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal outnorqst cleanup chain (rpcrdmarepput() plus rpcrdmapostrecvs()).(CVE-2026-72466)

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

xprtrdma: Decouple req recycling from RPC completion

rlkref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdmareq could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (scunmapcount > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer.

Give rlkref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdmapreparesendsges() takes a Send-side reference unconditionally after WR preparation succeeds. xprtrdmafreeslot() and xprtrdmabcfreerqst() drop the RPC-layer reference; rpcrdmasendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off.

The existing krefinit(&req->rlkref) call in rpcrdmapreparesendsges() is removed. Initialization moves to the slot-allocation paths (xprtrdmaallocslot and rpcrdmabcrqstget), and the release callback re-arms rlkref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry.

Three invariants follow:

• Any rpcrdmareq held by an rpcrqst has rlkref >= 1. xprtrdmaallocslot(), rpcrdmabcrqstget(), and the backlog-wake branch in xprtrdmaallocslot() each krefinit rlkref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gssrefresh failure or signal during callconnect, for example) would drive xprtrelease() -> xprtrdmafreeslot() -> krefput against a refcount of zero, saturating refcountt and stranding the slot.

• The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdmapreparesendsges() runs rpcrdmasendctxcancel(), which DMA-unmaps the sendctx and clears screq without touching rlkref. The sendctx ring walks in rpcrdmasendctxputlocked() and rpcrdmasendctxsdestroy() skip entries with screq == NULL, so a burst of -EIO marshal failures cannot hold reqs off rbsend_bufs.

• The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied.

Replies now complete the RPC directly. rpcrdmareplyhandler() calls rpcrdmacompleterqst() in place of krefput on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwrunmap_async() and is unaffected.

Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdmasendctxsdestroy() walks the active range and runs rpcrdmasendctxunmap() on each entry with a non-NULL screq before the request buffers are reset, and is moved ahead of rpcrdmareqsreset() in rpcrdmaxprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released.

The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bcprealloc req from rpcrdmareqrelease() re-adds it to bcpalist. The disconnect in xprtrdmadestroy() runs after xprtdestroybackchannel() has already emptied bcpalist, so the drained reqs would otherwise leak. xprtrdmadestroy() now runs xprtrdmabcdestroy(xprt, 0) a second time after the disconnect to reclaim them.(CVE-2026-72473)

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

fs/ntfs3: add bounds check to rungethighest_vcn()

rungethighest_vcn() parses a packed NTFS mapping-pairs buffer without any length bound, relying solely on a 0x00 terminator to stop. A crafted $LogFile UpdateMappingPairs record whose embedded attribute contains mapping-pairs runs without a terminator causes the function to read past the slab allocation, triggering a KASAN slab-out-of-bounds read on mount.

The sibling function rununpack() received an analogous bounds-check in commit b62567bca474 ("ntfs3: add buffer boundary checks to rununpack()"), but rungethighest_vcn() was missed.

Take a runbufsize parameter and reject any run header whose payload would extend past the buffer end, mirroring the pattern used by run_unpack(). The caller in fslog.c passes the remaining attribute bytes after the mapping-pairs offset.

KASAN report (on mainline v7.1 merge window HEAD):

BUG: KASAN: slab-out-of-bounds in rungethighestvcn+0x3c0/0x410 Read of size 1 at addr ffff88800e2d5400 by task mount/72 Call Trace: rungethighestvcn+0x3c0/0x410 doaction.isra.0+0x3ba8/0x7b50 logreplay+0x9ddd/0x10200 ntfsloadlogandreplay+0x4ad/0x610 ntfsfill_super+0x214a/0x4540(CVE-2026-72478)

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

bpf: Guard _getuser acesss with accessok for uprobemulti data

As reported by sashiko [1] we need to use access_ok to check the user space data bounds before we use __get-user to get it.

[1] https://lore.kernel.org/bpf/(CVE-2026-74258)

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

power: supply: core: fix supplied_from allocations

If dts property power-supplies has multiple values, then accessing to psy->supplied_from[i-1] in _powersupplypopulatesuppliedfrom will overrun suppliedfrom array.(CVE-2026-74271)

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

tipc: require net admin for TIPCv2 netlink mutators

TIPCv2 registers mutating generic-netlink operations without admin permission flags. Generic netlink only checks CAPNETADMIN when an operation sets GENLADMINPERM or GENLUNSADMINPERM, so a local unprivileged process can currently change TIPC state through commands such as TIPCNLNETSET, TIPCNLKEYSET, TIPCNLKEYFLUSH, and bearer enable/disable.

The legacy TIPC netlink API already checks netlinknetcapable(..., CAPNETADMIN) for administrative commands. Give the TIPCv2 mutators the equivalent generic-netlink gate. Use GENLUNSADMINPERM, which maps to the same namespace-aware CAPNETADMIN check that netlinknetcapable() performs, so the behaviour matches the legacy path and keeps working for CAPNET_ADMIN holders in a non-initial user namespace (containers).

A QEMU/KASAN repro run as uid/gid 65534 with zero effective capabilities previously succeeded in changing the network id and node identity, setting and flushing key material, and enabling/disabling a UDP bearer. With this patch applied the same operations fail with -EPERM.(CVE-2026-74283)

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

sctp: validate embedded address parameter length

sctpverifyasconf() and sctpverifyparam() only validate ADDIP, DELIP, and SETPRIMARY parameters against a fixed minimum size of sizeof(struct sctpaddipparam) + sizeof(struct sctpparamhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter.

Later, sctpprocessparam() and sctpprocessasconfparam() extract the embedded address parameter and pass it to af->fromaddr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter.

Validate that addrparam->p.length does not exceed the space available after the sctpaddip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds.

This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.(CVE-2026-74287)

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

bpf: Tighten cgroup storage cookie checks for prog arrays

The fix in commit abad3d0bad72 ("bpf: Fix oob access in cgroup local storage") is still incomplete. The prog-array compatibility check treats a program with no cgroup storage as compatible with any stored storage cookie. This allows a storage-less program to bridge a tail call chain between an entry program and a storage-using callee even though cgroup local storage at runtime still follows the caller's context, that is, A -> B(no storage) -> C(storage) path.

Requiring exact cookie equality would break the legitimate case of a storage-less leaf program being tail called from a storage-using one. Instead, only accept a zero storage cookie if the program cannot perform tail calls itself. This keeps A -> B(no storage) working while rejecting the A -> B(no storage) -> C(storage) bridge.(CVE-2026-74305)

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

bpf: Reject sleepable BPFLSMCGROUP programs at load time

The cgroup shim runs under rcureadlockdontmigrate(), so we should not attach any sleepable BPF programs there. Add support to the verifier to explicitly reject attempts to load sleepable BPF programs destined for LSM cgroup attachment.

Without this, we get the following splat from a BPFLSMCGROUP program marked BPFFSLEEPABLE attached to fileopen when it calls bpfgetdentryxattr():

BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1567 inatomic(): 0, irqsdisabled(): 0, nonblock: 0, pid: 34317, name: load preemptcount: 0, expected: 0 RCU nest depth: 2, expected: 0 Call Trace: downread+0x76/0x480 ext4xattr_get+0x11f/0x700 __vfsgetxattr+0xf0/0x150 bpfgetdentryxattr+0xbb/0xf0 bpfproge76a298dac9218c6testopen+0x6a/0x85 __cgroupbpfrunlsmcurrent+0x326/0x840 bpftrampoline6442534646+0x62/0x14d securityfileopen+0x34/0x60 dodentryopen+0x340/0x1260 vfsopen+0x7a/0x440 pathopenat+0x1bac/0x30a0

libbpf provides a .s named section variant for every sleepable program type except lsm_cgroup, reflecting that per-cgroup LSM programs are intended to only run in a non-sleepable context.

The above splat was obtained by bypassing libbpf by using bpf(2) directly.(CVE-2026-74338)

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

bpf: Clear rb node linkage when freeing bpfrbroot

bpfrbrootfree() detaches the root by copying the current rbrootcached and then replacing the live root with RBROOT_CACHED. It then walks the copied root and drops each object contained in the tree.

This leaves the rb node state intact while dropping the object. If the object is refcounted and survives the drop, its bpfrbnodekern still contains an owner pointer to the freed root and stale rb tree linkage. If a later bpfrbroot allocation reuses the same address, bpfrbtreeremove() can incorrectly pass the owner check and call rberase_cached() on a node whose rb pointers belong to the old tree.

Mirror the list draining behavior by marking nodes as busy while the root is being detached, then clear the rb node and release the owner before dropping the containing object. This makes surviving nodes unowned and safe to reject from remove or accept for a later add.(CVE-2026-74344)

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

bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs

commit 4f375ade6aa9 ("bpf: Avoid RCU context warning when unpinning htab with internal structs") moved inode cleanup from ->freeinode() into ->destroyinode() to avoid sleeping in RCU context when calling bpfanyput(). However this removed the RCU delay on freeing the inode itself and the cached symlink body (ilink), both of which can be accessed by RCU pathwalk (picklink, may_lookup etc.).

This causes a use-after-free when a concurrent unlinkat() drops the last inode reference and destroyinode() frees the inode immediately, while another task is still walking the path in RCU mode and reads inode->iopflags (offset +2) inside currenttime() -> ismgtime().

KASAN reports: BUG: KASAN: slab-use-after-free in ismgtime include/linux/fs.h:2313 Read of size 2 at addr ffff8880407e4282 (offset +2 = iopflags)

The rules (per Al Viro): ->destroyinode() called immediately, can sleep, use for blocking cleanup e.g. bpfanyput() ->freeinode() called after RCU grace period, use for freeing inode and anything RCU-accessible e.g. i_link

Fix: split the two concerns properly: - keep bpfanyput() in bpfdestroyinode() since it is blocking and needs to run promptly - introduce bpffreeinode() to handle kfree(ilink) and freeinode_nonrcu() with proper RCU delay, preventing the UAF(CVE-2026-74363)

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

RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path

For non-SRQ QPs, the responder reads WQE fields directly from the shared queue buffer mapped into userspace. This allows a malicious user to modify fields like numsge or sge entries while the kernel is processing the WQE, leading to out-of-bounds reads in rxerespchecklength() and copy_data().

Introduce getrecvwqe() that validates numsge and copies the WQE to a kernel-local buffer before processing, matching the approach already used for SRQ WQEs in getsrqwqe(). The srqwqe buffer is reused since SRQ and non-SRQ paths are mutually exclusive per QP.(CVE-2026-74377)

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

RDMA/rxe: Fix TOCTOU heap overflow in getsrqwqe

getsrqwqe() reads wqe->dma.numsge from the shared receive queue buffer, which is mapped into userspace. It validates numsge against maxsge, but then re-reads the same field to calculate the memcpy size. A concurrent userspace thread can modify numsge between validation and use, causing a heap buffer overflow when copying the WQE into qp->resp.srq_wqe.

Read num_sge into a local variable and use it for both the bounds check and the size calculation.(CVE-2026-74378)

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

RDMA/srpt: fix integer overflow in immediate data length check

immbuf->len is a user-controlled uint32t received from the network. Adding it to immdataoffset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing reqsize to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sginit_one().

Use checkaddoverflow() to detect wrapping before the comparison.(CVE-2026-74394)

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

IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier

mlx5iballoctransportdomain() allocates a transport domain and then may fail in mlx5ibenable_lb(). In that case, the allocated TD is leaked.

Fix this by deallocating the TD when mlx5ibenablelb() returns an error. Also return 0 explicitly in the no-loopback-capability success branch, and move dev->lb.mutex initialization to mlx5ibstageinit_init().(CVE-2026-74397)

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

ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD

addrconfdadfailure() transitions ifp->state from DAD to POSTDAD via addrconfdadend(), which drops ifp->lock on return. The lock is re-acquired after netinforatelimited(). A concurrent ipv6deladdr() can take the lock in that window, set ifp->state to DEAD and run listdelrcu(&ifp->if_list).

addrconfdadfailure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dadwork. The work calls ipv6del_addr() again, hitting the already-poisoned list entry:

general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6addrconf addrconfdadwork RIP: 0010:ipv6deladdr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconfdadstop+0x113/0x140 addrconfdadwork+0x28c/0x430 processonework+0x1eb/0x3b0 workerthread+0x4d/0x400 kthread+0x104/0x140 retfromfork+0x35/0x40

Fold the addrconfdadend() logic into addrconfdadfailure() under a single ifp->lock critical section. The STABLEPRIVACY branch temporarily drops ifp->lock around address regeneration, so at lockerrdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.(CVE-2026-74398)

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

vxlan: Fix potential null-ptr-deref in vxlangroprepare_receive().

udptunnelsockrelease() could set sk->skuserdata to NULL while vxlangropreparereceive() is running.

Let's check if rcudereferenceskuserdata() is NULL after skbgroremcsum_init().(CVE-2026-74406)