OESA-2026-3532

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

uaccess: fix integer overflow on access_ok()

Three architectures check the end of a user access against the address limit without taking a possible overflow into account. Passing a negative length or another overflow in here returns success when it should not.

Use the most common correct implementation here, which optimizes for a constant 'size' argument, and turns the common case into a single comparison.(CVE-2022-49289)

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

parisc: Fix double SIGFPE crash

Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately.

When the T bit is set, an assist exception trap occurs when when the co-processor encounters any floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace.

The issue can be reproduced with this test program:

root@parisc:~# cat fpe.c

static void fpefunc(int sig, siginfot *i, void *v) { sigsett set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIGUNBLOCK, &set, NULL); printf("GOT signal %d with sicode %ld\n", sig, i->sicode); }

int main() { struct sigaction action = { .sasigaction = fpefunc, .saflags = SARESTART|SASIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FEOVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); }

root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception

root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 /* 20 vars /) = 0 getrlimit(RLIMITSTACK, {rlimcur=81921024, rlimmax=RLIMINFINITY}) = 0 ... rtsigaction(SIGFPE, {sahandler=0x1110a, samask=[], saflags=SARESTART|SASIGINFO}, NULL, 8) = 0 --- SIGFPE {sisigno=SIGFPE, sicode=FPEFLTOVF, siaddr=0x1078f} --- --- SIGFPE {sisigno=SIGFPE, sicode=FPEFLTOVF, siaddr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception(CVE-2025-37991)

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

drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpuatomexecutetablelocked()

kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.wssize is set, leading to a potential NULL pointer dereference in atomgetsrcint() when accessing WS entries.

Return -ENOMEM on allocation failure to avoid the NULL dereference.(CVE-2025-68190)

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

arm64/fpsimd: signal: Fix restoration of SVE context

When SME is supported, Restoring SVE signal context can go wrong in a few ways, including placing the task into an invalid state where the kernel may read from out-of-bounds memory (and may potentially take a fatal fault) and/or may kill the task with a SIGKILL.

(1) Restoring a context with SVESIGFLAGSM set can place the task into an invalid state where SVCR.SM is set (and svestate is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL.

This can only occur in unusual (but legitimate) cases where the SVE
signal context has either been modified by userspace or was saved in
the context of another task (e.g. as with CRIU), as otherwise the
presence of an SVE signal context with SVE_SIG_FLAG_SM implies that
TIF_SME is already set.

While in this state, task_fpsimd_load() will NOT configure SMCR_ELx
(leaving some arbitrary value configured in hardware) before
restoring SVCR and attempting to restore the streaming mode SVE
registers from memory via sve_load_state(). As the value of
SMCR_ELx.LEN may be larger than the task's streaming SVE vector
length, this may read memory outside of the task's allocated
sve_state, reading unrelated data and/or triggering a fault.

While this can result in secrets being loaded into streaming SVE
registers, these values are never exposed. As TIF_SME is clear,
fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0
accesses to streaming mode SVE registers, so these cannot be
accessed directly at EL0. As fpsimd_save_user_state() verifies the
live vector length before saving (S)SVE state to memory, no secret
values can be saved back to memory (and hence cannot be observed via
ptrace, signals, etc).

When the live vector length doesn't match the expected vector length
for the task, fpsimd_save_user_state() will send a fatal SIGKILL
signal to the task. Hence the task may be killed after executing
userspace for some period of time.

(2) Restoring a context with SVESIGFLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV.

This can only occur in unusual (but legitimate) cases where ptrace
has been used to set SVCR.SM after entry to the sigreturn syscall,
as syscall entry clears SVCR.SM.

In these cases, the the provided SVE register data will be loaded
into the task's sve_state using the non-streaming SVE vector length
and the FPSIMD registers will be merged into this using the
streaming SVE vector length.

Fix (1) by setting TIFSME when setting SVCR.SM. This also requires ensuring that the task's smestate has been allocated, but as this could contain live ZA state, it should not be zeroed. Fix (2) by clearing SVCR.SM when restoring a SVE signal context with SVESIGFLAG_SM clear.

For consistency, I've pulled the manipulation of SVCR, TIFSVE, TIFSME, and fptype earlier, immediately after the allocation of svestate/sme_state, before the restore of the actual register state. This makes it easier to ensure that these are always modified consistently, even if a fault is taken while reading the register data from the signal context. I do not expect any software to depend on the exact state restored when a fault is taken while reading the context.(CVE-2026-23102)

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

net: ncsi: fix skb leak in error paths

Early return paths in NCSI RX and AEN handlers fail to release the received skb, resulting in a memory leak.

Specifically, ncsiaenhandler() returns on invalid AEN packets without consuming the skb. Similarly, ncsircvrsp() exits early when failing to resolve the NCSI device, response handler, or request, leaving the skb unfreed.(CVE-2026-43373)

In the Linux kernel, the following vulnerability has been resolved: selinux: fix overlayfs mmap() and mprotect() access checks The existing SELinux security model for overlayfs is to allow access if the current task is able to access the top level file (the "user" file) and the mounter's credentials are sufficient to access the lower level file (the "backing" file). Unfortunately, the current code does not properly enforce these access controls for both mmap() and mprotect() operations on overlayfs filesystems. This patch makes use of the newly created securitymmapbacking_file() LSM hook to provide the missing backing file enforcement for mmap() operations, and leverages the backing file API and new LSM blob to provide the necessary information to properly enforce the mprotect() access controls. The Linux kernel CVE team has assigned CVE-2026-46054 to this issue.(CVE-2026-46054)

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

fbcon: Avoid OOB font access if console rotation fails

Clear the font buffer if the reallocation during console rotation fails in fbconrotatefont(). The putcs implementations for the rotated buffer will return early in this case. See [1] for an example.

Currently, fbconrotatefont() keeps the old buffer, which is too small for the rotated font. Printing to the rotated console with a high-enough character code will overflow the font buffer.

v2: - fix typos in commit message(CVE-2026-46191)

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

vsock: fix buffer size clamping order

In vsockupdatebuffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint.

This breaks the intended socket memory boundaries by allowing the vsk->buffersize to grow beyond the configured vsk->buffermax_size.

Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffermaxsize.(CVE-2026-46234)

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

Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths

Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart.

The primary issue arises because the workqueues (initready and writework) are only flushed/cancelled if the HCIUARTPROTOREADY flag is set during TTY close. If a hangup occurs before setup completes, hciuartttyclose() skips the teardown of these workqueues and proceeds to free the hu struct. When the scheduled work executes later, it blindly dereferences the freed hu struct.

Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hciuartflush() from hciuartclose() without effectively disabling writework causes a race condition where both can concurrently double-free hu->txskb. This happens because protocol timers can concurrently invoke hciuarttxwakeup() and requeue writework. 2. Calling hcifreedev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the protolock write lock before clearing PROTOREADY leads to races with active readers. Additionally, hciuarttty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently.

Fix these synchronization and lifecycle issues by: 1. Re-ordering hciuartttyclose() to clear HCIUARTPROTOREADY first, followed immediately by a cancelworksync(&hu->writework). Clearing the flag locks out concurrent protocol timers from successfully invoking hciuarttxwakeup(), effectively rendering the cancellation permanent and preventing the txskb double-free. 2. Note: Clearing PROTOREADY early causes hciuartclose() to skip hu->proto->flush(). This is perfectly safe in the ttyclose path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hcifreedev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byterx increment in hciuartttyreceive() inside the protolock read-side critical section to safely synchronize with device unregistration. 5. Adding cancelworksync(&hu->writework) to hciuartclose() to safely flush the workqueue before hciuartflush() is invoked via the HCI core. 6. Utilizing cancelworksync() instead of disablework_sync() across all paths to prevent permanently breaking user-space retry capabilities.(CVE-2026-46275)

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

fs/ntfs3: terminate the cached volume label after UTF-8 conversion

ntfsfillsuper() loads the on-disk volume label with utf16stoutf8s() and stores the result in sbi->volume.label. The converted label is later exposed through ntfs3labelshow() using %s, but utf16stoutf8s() only returns the number of bytes written and does not add a trailing NUL.

If the converted label fills the entire fixed buffer, ntfs3labelshow() can read past the end of sbi->volume.label while looking for a terminator.

Terminate the cached label explicitly after a successful conversion and clamp the exact-full case to the last byte of the buffer.(CVE-2026-53023)

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

ocfs2/dlm: validate qrnumregions in dlmmatch_regions()

Patch series "ocfs2/dlm: fix two bugs in dlmmatchregions()".

In dlmmatchregions(), the qrnumregions field from a DLMQUERYREGION network message is used to drive loops over the qrregions buffer without sufficient validation. This series fixes two issues:

• Patch 1 adds a bounds check to reject messages where qrnumregions exceeds O2NMMAXREGIONS. The o2net layer only validates message byte length; it does not constrain field values, so a crafted message can set qrnumregions up to 255 and trigger out-of-bounds reads past the 1024-byte qr_regions buffer.

• Patch 2 fixes an off-by-one in the local-vs-remote comparison loop, which uses '<=' instead of '<', reading one entry past the valid range even when qr_numregions is within bounds.

This patch (of 2):

The qrnumregions field from a DLMQUERYREGION network message is used directly as loop bounds in dlmmatchregions() without checking against O2NMMAXREGIONS. Since qrregions is sized for at most O2NMMAXREGIONS (32) entries, a crafted message with qrnumregions > 32 causes out-of-bounds reads past the qrregions buffer.

Add a bounds check for qr_numregions before entering the loops.(CVE-2026-53043)

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

wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irqpreparebcn_tasklet

The irqpreparebcntasklet is initialized in rtlpciinit() and scheduled when RTLIMRBCNINT interrupt is triggered by hardware. But it is never killed in rtlpcideinit(). When the rtlwifi card probe fails or is being detached, the ieee80211hw is deallocated. However, irqpreparebcntasklet may still be running or pending, leading to use-after-free when the freed ieee80211hw is accessed in rtlpcipreparebcn_tasklet().

Similar to irqtasklet, add taskletkill() in rtlpcideinit() to ensure that irqpreparebcntasklet is properly terminated before the ieee80211hw is released.

The issue was identified through static analysis.(CVE-2026-53112)

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

PCI: use generic driver_override infrastructure

When a driver is probed through __driverattach(), the bus' match() callback is called without the device lock held, thus accessing the driveroverride field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.

Note that calling match() from _driverattach() without the device lock held is intentional. 1

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

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

A tunnel changelink() 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 devnet(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.

Add rtnldevlinknetcapable() next to rtnlgetnetnscapable() in net/core/rtnetlink.c. It requires CAPNETADMIN in the link netns and is skipped when the link netns is dev_net(dev), where the rtnl path already checked it. The other patches in this series use the same helper.

Gate ipgrechangelink() and erspanchangelink() with it, at the top of the op before any attribute is parsed, because the parsers update live tunnel fields first. ipgrenetlinkparms() sets t->collectmd before iptunnel_changelink() runs.

Commit 8b484efd5cb4 ("ip6: vti: Use ip6tnl.net in vti6siocdevprivate().") added the same check on the ioctl path. This adds it on RTM_NEWLINK.(CVE-2026-63829)

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

ipv6: validate extension header length before copying to cmsg

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) << 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:

BUG: KASAN: slab-out-of-bounds in putcmsg+0x3ac/0x540 putcmsg+0x3ac/0x540 udpv6recvmsg+0xca0/0x1250 sockrecvmsg+0xdf/0x190 ___sysrecvmsg+0x1b1/0x620

Add ipv6getexthdrlen() which validates that at least two bytes are accessible before reading the hdrlen field, then checks the computed length against skbtailpointer(skb), returning 0 on failure. Extension headers are kept in the linear skb area by pskbmaypull() during input, so skbtail_pointer() is the correct bound.

Use ipv6getexthdr_len() at all non-AH call sites: the five standalone cmsg blocks (HbH, 2292HbH, 2292DSTOPTS x2, 2292RTHDR) and the three standard cases in the extension-header walk loop (DSTOPTS, ROUTING, default). AH retains an inline bounds check because its length formula differs ((ptr[1]+2)<<2).

The walk loop also gets a pre-read bounds check at the top to validate ptr before any case accesses ptr[0] or ptr[1].

When the walk loop detects a corrupted header, return from the function instead of continuing to process later socket options.(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:

netfilter: synproxy: refresh tcphdr after skbensurewritable

synproxytstampadjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inetprotocsumreplace4() on the caller-supplied tcphdr pointer. Both ipv4synproxyhook() and ipv6synproxyhook() obtain that pointer with skbheader_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer.

Between obtaining the pointer and using it, the function calls skbensurewritable(skb, optend), which on a cloned or non-linear skb invokes pskbexpandhead() and frees the old skb->head. After that point the cached th is stale:

caller (ipv[46]_synproxy_hook)
  th = skb_header_pointer(skb, ..., &_tcph)
  synproxy_tstamp_adjust(skb, protoff, th, ...)
    skb_ensure_writable(skb, optend)
      pskb_expand_head()        /* kfree(old skb->head) */
    ...
    inet_proto_csum_replace4(&th->check, ...)
                                /* writes into freed head, or
                                   into the caller's stack copy
                                   leaving the on-wire checksum
                                   stale */

The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload.

Fix by re-deriving th from skb->data + protoff immediately after skbensurewritable() succeeds, so the subsequent checksum update targets the linear, writable header.(CVE-2026-64007)

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:

ALSA: asihpi: Fix potential OOB array access at reading cache

find_control() to retrieve a cached info accesses the array with the given index blindly, which may lead to an OOB array access. Add a sanity check for avoiding it.(CVE-2026-64133)

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

fuse: re-lock request before returning from fusereffolio()

fusereffolio() unlocks the request but does not re-lock it before returning. fusechanabort() can end the request and the async end callback (eg fusewritepagefree()) can free the args while the subsequent copy chain logic after fusereffolio() accesses them, leading to use-after-free issues.

Fix this by locking the request in fusereffolio() before returning.(CVE-2026-64266)

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

net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes

Reject invalid net.ipv4.tcp_reordering values before they reach TCP socket state. The sysctl is stored as an int but copied into the u32 tp->reordering field for new sockets, so negative writes wrap to large values.

With tcp_mtu_probing=2, the wrapped value can overflow the tcp_mtu_probe() size calculation and drive the MTU probing path into an out-of-bounds read. Route tcp_reordering writes through proc_dointvec_minmax() and require it to be at least 1. Also require tcp_max_reordering to be at least 1 so the configured maximum cannot become negative either.

When registering the table for a non-init network namespace, relocate extra2 pointers that refer into init_net.ipv4 so the tcp_reordering upper bound follows that namespace's tcp_max_reordering.

Harden tcp_mtu_probe() itself by computing size_needed as u64. This keeps the send queue and window checks from being bypassed through signed integer overflow.(CVE-2026-64422)

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

net: afkey: initialize algkey_len for IPComp states

pfkeymsg2xfrmstate() handles the IPComp (SADBXSATYPE_IPCOMP) case by allocating x->calg and copying only the algorithm name:

x->calg = kmalloc_obj(*x->calg);
if (!x->calg) {
    err = -ENOMEM;
    goto out;
}
strcpy(x->calg->alg_name, a->name);
x->props.calgo = sa->sadb_sa_encrypt;

Unlike the authentication (x->aalg) and encryption (x->ealg) branches of the same function, the compression branch never initializes calg->algkeylen. IPComp carries no key and the allocation only reserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field is left containing uninitialized slab data.

calg->algkeylen is later used as a length by xfrmalgoclone() when an IPComp state is cloned during XFRMMSGMIGRATE:

xfrm_state_migrate()
  xfrm_state_clone_and_setup()
    x->calg = xfrm_algo_clone(orig->calg);
      kmemdup(orig, xfrm_alg_len(orig));

where xfrmalglen() returns sizeof(*alg) + (algkeylen + 7) / 8. With a non-zero garbage algkeylen, kmemdup() reads past the end of the 68-byte calg object. Adding an IPComp SA via PFKEY and then migrating it triggers (net-next, KASAN, initon_alloc=0):

BUG: KASAN: slab-out-of-bounds in kmemdupnoprof+0x44/0x60 Read of size 4164 at addr ff11000025a74980 by task diag2/9287 CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1 Call Trace: <TASK> dumpstacklvl+0x10e/0x1f0 printreport+0xf7/0x600 kasanreport+0xe4/0x120 kasancheck_range+0x105/0x1b0 __asanmemcpy+0x23/0x60 kmemdupnoprof+0x44/0x60 xfrmstatemigrate+0x70a/0x1da0 xfrmmigrate+0x753/0x18a0 xfrmdomigrate+0xb47/0xf10 xfrmuserrcvmsg+0x411/0xb50 netlinkrcvskb+0x158/0x420 xfrmnetlinkrcv+0x71/0x90 netlinkunicast+0x584/0x850 netlinksendmsg+0x8b0/0xdc0 ____sys_sendmsg+0x9f7/0xb90 ___sys_sendmsg+0x134/0x1d0 _syssendmsg+0x16d/0x220 dosyscall64+0x116/0x7d0 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

Allocated by task 9287: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 __kasankmalloc+0xaa/0xb0 pfkeyadd+0x2652/0x2ea0 pfkeyprocess+0x6d0/0x830 pfkeysendmsg+0x42c/0x850 __sys_sendto+0x461/0x4b0 __x64syssendto+0xe0/0x1c0 dosyscall64+0x116/0x7d0 entrySYSCALL64afterhwframe+0x77/0x7f

The buggy address belongs to the object at ff11000025a74980 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes inside of allocated 68-byte region [ff11000025a74980, ff11000025a749c4)

Depending on the uninitialized value the same field can instead request an oversized kmemdup() allocation and make the migration clone fail.

The XFRM netlink path is not affected: verifyonealg() rejects an XFRMAALGCOMP attribute shorter than xfrmalglen(), so a calg added via XFRMMSGNEWSA is always self-consistent.

Initialize calg->algkeylen to 0, matching the aalg/ealg branches.(CVE-2026-64436)

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

drm/edid: fix OOB read in drmparsetiled_block()

drmparsetiledblock() casts the DisplayID block to a struct displayidtiledblock and reads the full fixed layout up to tile->topologyid[7] without checking block->numbytes. The DisplayID iterator only validates the declared payload length, so a crafted EDID can advertise a tiled-display block (tag DATABLOCKTILEDDISPLAY, or DATABLOCK2TILEDDISPLAYTOPOLOGY for v2.0) with a small numbytes at the end of a DisplayID extension. The read then runs past the end of the exact-sized kmemdup()'d EDID allocation, a heap out-of-bounds read.

Reject blocks shorter than the spec's 22-byte tiled payload before reading the fixed struct, as drmparsevesamsodata() already does.

BUG: KASAN: slab-out-of-bounds in drmedidconnectorupdate Read of size 2 at addr ffff888010077700 by task exploit/147 dumpstacklvl (lib/dumpstack.c:94 ...) printreport (mm/kasan/report.c:378 ...) kasanreport (mm/kasan/report.c:595) drmedidconnectorupdate (drivers/gpu/drm/drmedid.c:7581) bochsconnectorhelpergetmodes (drivers/gpu/drm/tiny/bochs.c:574) drmhelperprobesingleconnectormodes (drivers/gpu/drm/drmprobehelper.c:426) statusstore (drivers/gpu/drm/drmsysfs.c:219) ... vfswrite (fs/readwrite.c:595 fs/readwrite.c:688) ksyswrite (fs/readwrite.c:740)(CVE-2026-64546)

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

Bluetooth: qca: fix NVM tag length underflow in TLV parser

In the TLVTYPENVM branch of qcatlvcheckdata() the tag loop bound is "while (idx < length - sizeof(struct tlvtypenvm))". "length" is a signed int from the firmware TLV header and sizeof(struct tlvtypenvm) is a sizet (12), so "length" is converted to sizet and any firmware-supplied "length" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlvtypenvm past the end of the short vmalloc'd firmware buffer (and the EDLTAGID* handlers can write past it).

Rewrite the bound as "idx + sizeof(struct tlvtypenvm) <= length"; both operands are non-negative, so it no longer underflows and a "length" too small for one record correctly skips the loop.

BUG: KASAN: vmalloc-out-of-bounds in qcadownloadfirmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hcipoweron Call Trace: ... kasanreport (mm/kasan/report.c:595) qcadownloadfirmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qcauartsetup (drivers/bluetooth/btqca.c:948) qcasetup (drivers/bluetooth/hciqca.c:2029) hciuartsetup (drivers/bluetooth/hcildisc.c:438) hcidevopensync (net/bluetooth/hcisync.c:5227) hcipoweron (net/bluetooth/hcicore.c:920) processonework (kernel/workqueue.c:3322) workerthread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245)(CVE-2026-64573)

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

ceph: fix pre-auth out-of-bounds read on snaptrace in cephhandlecaps()

cephhandlecaps() reads snaptracelen from the wire-format cephmdscaps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptracelen) that is later handed to cephupdatesnaptrace() in the CEPHCAPOP_IMPORT case:

snaptrace     = h + 1;
snaptrace_len = le32_to_cpu(h->snap_trace_len);
p             = snaptrace + snaptrace_len;
...
case CEPH_CAP_OP_IMPORT:
    if (snaptrace_len) {
        ...
        if (ceph_update_snap_trace(mdsc, snaptrace,
                                   snaptrace + snaptrace_len,
                                   false, &realm)) { ... }

cephupdatesnaptrace() then decodes a struct cephmdssnaprealm from snaptrace using cephdecodeneed(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptracelen. With snaptracelen == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct cephmdssnaprealm) past the legitimate msg->front buffer, and ri->numsnaps / ri->numpriorparent_snaps then drive further out-of-bounds reads of the encoded snap arrays.

The eleven msgversion >= 2 .. msgversion >= 12 decoder blocks above the op switch each catch this OOB through their cephdecode*safe() / cephdecodeneed() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snaptracelen. The shape has been present since cephhandle_caps() was introduced.

Validate snaptracelen against the message front buffer before consuming it, using the canonical cephdecodeneed() / cephhasroom() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snaptracelen could overflow the address space. This matches the rest of the ceph decode path (e.g. the poolnslen check a few lines below), and the existing goto bad cleanup already covers this exit path.(CVE-2026-68160)

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:

netfilter: xt_u32: reject invalid shift counts

u32matchit() executes rule-supplied shift operands on a 32-bit value. A malformed u32 rule can provide a shift count of 32 or more, triggering an undefined shift out-of-bounds during packet evaluation.

Validate XTU32LEFTSH and XTU32RIGHTSH operands in u32mtcheckentry() and reject malformed rules before they reach the packet path.(CVE-2026-72350)