OESA-2026-3453

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

wifi: cfg80211: cancel rfkillblock work in wiphyunregister()

There is a use-after-free error in cfg80211shutdownall_interfaces found by syzkaller:

BUG: KASAN: use-after-free in cfg80211shutdownallinterfaces+0x213/0x220 Read of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326 CPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events cfg80211rfkillblockwork Call Trace: <TASK> dumpstacklvl+0x116/0x1f0 printreport+0xcd/0x630 kasanreport+0xe0/0x110 cfg80211shutdownallinterfaces+0x213/0x220 cfg80211rfkillblockwork+0x1e/0x30 processonework+0x9cf/0x1b70 workerthread+0x6c8/0xf10 kthread+0x3c5/0x780 retfromfork+0x56d/0x700 retfromforkasm+0x1a/0x30 </TASK>

The problem arises due to the rfkillblock work is not cancelled when wiphy is being unregistered. In order to fix the issue cancel the corresponding work in wiphyunregister().

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2026-23336)

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

Bluetooth: L2CAP: Fix type confusion in l2capecredreconf_rsp()

l2capecredreconfrsp() casts the incoming data to struct l2capecredconnrsp (the ECRED connection response, 8 bytes with result at offset 6) instead of struct l2capecredreconf_rsp (2 bytes with result at offset 0).

This causes two problems:

• The sizeof(*rsp) length check requires 8 bytes instead of the correct 2, so valid L2CAPECREDRECONF_RSP packets are rejected with -EPROTO.

• rsp->result reads from offset 6 instead of offset 0, returning wrong data when the packet is large enough to pass the check.

Fix by using the correct type. Also pass the already byte-swapped result variable to BT_DBG instead of the raw __le16 field.(CVE-2026-43062)

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

apparmor: Fix & Optimize table creation from possibly unaligned memory

Source blob may come from userspace and might be unaligned. Try to optize the copying process by avoiding unaligned memory accesses.

• Added Fixes tag
• Added "Fix &" to description as this doesn't just optimize but fixes a potential unaligned memory access jj: remove duplicate word "convert" in comment trigger checkpatch warning

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

md/raid5: validate payload size before accessing journal metadata

r5crecoveryanalyzemetablock() and r5lrecoveryverifydatachecksumformb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block.

A corrupted journal contains payload sizes extending beyond the PAGE_SIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets.

Add bounds validation for each payload type to ensure the full payload fits within meta_size before processing.(CVE-2026-46070)

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

KVM: x86: Fix shadow paging use-after-free due to unexpected GFN

The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE", 2026-03-27). The flow is as follows:

• a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvmmmupage consisting of 512 4KB pages; the kvmmmupage is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous).

• the PDE mapping is changed from outside the guest.

• the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the "correct" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvmmmupage is zapped.

• the memslot that covers the first 2MB mapping is deleted, and the kvmmmupage for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3.

• any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvmmmupage. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED).

The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvmmmupage must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but actually only happens in response to a guest write.

That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the "wrong" shadow page. However, that was only an imprecision until 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages") came along.

Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.(CVE-2026-46113)

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

NFSv4/flexfiles: reject zero filehandle version count

fflayoutalloclseg() decodes the filehandle-version array count from the flexfiles layout body. The value is used as the count for kzallocobjs(), and the current code only rejects NULL.

A zero count yields ZEROSIZEPTR, which can be stored in dssinfo->fhversions even though later flexfiles paths assume that at least one filehandle version exists.

Reject fhcount == 0 before the allocation, matching the existing zero versioncount validation in the flexfiles GETDEVICEINFO parser.

A QEMU/KASAN run with a malformed flexfiles layout hit:

KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:fflayoutencodefflayoutupdate.isra.0+0x15f/0x750 fflayoutencodelayoutreturn+0x683/0x970 nfs4xdrenclayoutreturn+0x278/0x3a0 Kernel panic - not syncing: Fatal exception

The patched kernel rejects the malformed layout without KASAN/oops/panic, and a valid fh_count=1 regression still opens, reads, and unmounts cleanly.(CVE-2026-53392)

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

fbdev: fbcon: fix out-of-bounds read in errout of fbcondosetfont()

When fbcondosetfont() fails (e.g., due to a memory allocation failure inside vcresize() under heavy memory pressure), it jumps to the err_out label to roll back the console state. However, the current rollback logic forgets to restore the hi_font state, leading to a severe state machine corruption.

Earlier in the function, set_vc_hi_font() might be called to change vc->vc_hi_font_mask and mutate the screen buffer. If vc_resize() subsequently fails, the err_out path restores vc_font.charcount but entirely skips rolling back the vc_hi_font_mask and the screen buffer.

This mismatch leaves the terminal in a desynchronized state. Because vc_hi_font_mask remains set, the VT subsystem will still accept character indices greater than 255 from userspace and write them to the screen buffer. Subsequent rendering calls (e.g., fbcon_putcs()) will then use these inflated indices to access the reverted, 256-character font array, leading to a deterministic out-of-bounds read and potential kernel memory disclosure.

Fix this by adding the missing rollback logic for the hi_font mask and screen buffer in the error path.(CVE-2026-53402)

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:

RDMA/core: Prefer NLANULSTRING

These attributes are evaluated as c-string (passed to strcmp), but NLA_STRING doesn't check for the presence of a \0 terminator.

Either this needs to switch to nlastrcmp() and needs to adjust printf fmt specifier to not use plain %s, or this needs to use NLANUL_STRING.

As the code has been this way for long time, it seems to me that userspace does include the terminating nul, even tough its not enforced so far, and thus NLANULSTRING use is the simpler solution.(CVE-2026-63860)

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:

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:

Bluetooth: HIDP: fix missing length checks in hidpinputreport()

hidpinputreport() reads keyboard and mouse payload data from an skb without first verifying that skb->len contains enough data.

hidprecvintrframe() pulls the 1-byte HIDP header before dispatching to hidpinput_report(). If a paired device sends a truncated packet, the handler reads beyond the valid skb data, resulting in an out-of-bounds read of skb data. The OOB bytes may be interpreted as phantom key presses or spurious mouse movement.

Replace the open-coded length tracking and pointer arithmetic with skbpulldata() calls. skbpulldata() returns NULL if the requested bytes are not present, eliminating the need for a manual size variable and the separate skb->len guard.(CVE-2026-63947)

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:

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:

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:

Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count

rmif30mapgpios() allocates gpioledkeymap with min(gpioledcount, TRACKSTICKRANGEEND) == at most 6 entries, but rmif30attention() iterates the full f30->gpioledcount (device query register, range 0..31) and dereferences gpioledkeymap[i], and input->keycodemax is set to the full gpioledcount while input->keycode points at the 6-entry allocation.

A device that reports gpioled_count > 6 with GPIO support enabled therefore causes an out-of-bounds read on the attention interrupt and out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls, which bound the index only against keycodemax. This is the same defect as the F3A handler, which was copied from F30.

Size the keymap for the full gpioledcount; the mapping loop still assigns only the first min(gpioledcount, TRACKSTICKRANGEEND) entries.(CVE-2026-64276)

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

i2c: core: fix adapter deregistration race

Adapters can be looked up by their id using i2cgetadapter() which takes a reference to the embedded struct device.

Remove the adapter from the IDR before tearing it down during deregistration (and on registration failure) to make sure its resources are not accessed after having been freed (e.g. the device name).(CVE-2026-64279)

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

exfat: bound uniname advance in exfatfinddir_entry()

In exfatfinddirentry(), each TYPEEXTEND (file name) entry advances the output pointer by a fixed amount while the loop guard only tracks the accumulated name length:

if (++order == 2)
    uniname = p_uniname->name;
else
    uniname += EXFAT_FILE_NAME_LEN;
len = exfat_extract_uni_name(ep, entry_uniname);
name_len += len;
unichar = *(uniname+len);
*(uniname+len) = 0x0;

uniname grows by EXFATFILENAMELEN (15) per name entry, but namelen grows only by the actual extracted length, which is shorter when a name fragment contains an early NUL. The only guard is name_len >= MAX_NAME_LENGTH, so a crafted directory with many short name fragments lets uniname run far past the puniname->name[MAXNAMELENGTH + 3] buffer while namelen stays small, causing an out-of-bounds read and write at *(uniname+len).

The sibling extractor exfatgetuninamefromextentry() already stops on a short fragment (the lockstep len != EXFAT_FILE_NAME_LEN guard added in commit d42334578eba ("exfat: check if filename entries exceeds max filename length")); exfatfinddirentry() never got the equivalent. Track the per-entry write offset as a count and reject a fragment once the offset, or the offset plus the extracted length, would exceed MAXNAMELENGTH, before forming the output pointer.(CVE-2026-64296)

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:

USB: serial: digi_acceleport: fix write buffer corruption

The digiwriteinb_command() is supposed to wait for the write urb to become available or return an error, but instead it updates the transfer buffer and tries to resubmit the urb on timeout.

To make things worse, for commands like break control where no timeout is used, the driver would corrupt the urb immediately due to a broken jiffies comparison (on 32-bit machines this takes five minutes of uptime to trigger due to INITIAL_JIFFIES).

Fix this by adding the missing return on timeout and waiting indefinitely when no timeout has been specified as intended.

This issue was (sort of) flagged by Sashiko when reviewing an unrelated change to the driver.(CVE-2026-64333)

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

USB: legousbtower: fix use-after-free on disconnect race

mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2]

Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect().

[1] a51749ab34d9 ("locking/mutex: Document that mutexunlock() is non-atomic") [2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutexunlock(), and most other sleeping locks, can still use the lock object after it's unlocked")(CVE-2026-64340)

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

proc: protect ptracemayaccess() with execupdatelock (part 1)

Fix the easy cases where procfs currently calls ptracemayaccess() without execupdatelock protection, where the fix is to simply add the extra lock or use mm_access():

• dotaskstat(): grab execupdatelock
• procpidwchan(): grab execupdatelock
• procmapfileslookup(): use mmaccess() instead of gettaskmm()
• procmapfilesreaddir(): use mmaccess() instead of gettaskmm()
• procnsgetlink(): grab execupdate_lock
• procnsreadlink(): grab execupdatelock(CVE-2026-64371)

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

smb/client: fix chown/chgrp with SMB3 POSIX Extensions

Ownership (chown) and group (chgrp) modifications were being ignored when mounting with SMB3 POSIX Extensions unless CIFSMOUNTCIFSACL or CIFSMOUNTMODEFROM_SID were also explicitly set.

Fix this by checking for posixextensions in cifssetattrnounix() when updating UID and GID, ensuring that idmodetocifs_acl() is called to map and set the ownership/group information on the server.(CVE-2026-64388)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix UAF in btacceptdequeue(). btacceptget() takes a temporary reference before dropping the accept queue lock. btacceptdequeue() currently drops that reference before btacceptunlink(), leaving only the queue reference. btacceptunlink() drops the queue reference. The subsequent sock_hold() therefore accesses freed memory if it was the final reference, as observed by KASAN during listening L2CAP socket cleanup. Retain the temporary queue-walk reference through unlink and hand it to the caller on success. Drop it explicitly on the closed and not-yet-connected paths.(CVE-2026-64406)

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

net: qualcomm: rmnet: validate MAP frame length before ingress parsing

When ingress deaggregation is disabled, rmnetmapingress_handler() passes the skb straight to __rmnetmapingresshandler(), skipping the length validation that rmnetmapdeaggregate() performs on the aggregated path. The parser then dereferences the MAP header and csum header/trailer based on the on-wire pktlen without checking skb->len, so a short frame is read out of bounds:

BUG: KASAN: slab-out-of-bounds in rmnetmapchecksumdownlinkpacket Read of size 1 at addr ffff88801118ed00 by task exploit/147 Call Trace: ... rmnetmapchecksumdownlinkpacket (drivers/net/ethernet/qualcomm/rmnet/rmnetmapdata.c:413) __rmnetmapingress_handler (drivers/net/ethernet/qualcomm/rmnet/rmnethandlers.c:96) rmnetrxhandler (drivers/net/ethernet/qualcomm/rmnet/rmnethandlers.c:129) _netifreceiveskbcore.constprop.0 (net/core/dev.c:6089) netifreceiveskb (net/core/dev.c:6460) tungetuser (drivers/net/tun.c:1955) tunchrwriteiter (drivers/net/tun.c:2001) vfswrite (fs/readwrite.c:688) ksyswrite (fs/readwrite.c:740) dosyscall64 (arch/x86/entry/syscall64.c:94) ...

Factor that validation out of rmnetmapdeaggregate() into rmnetmapvalidatepacketlen() and run it on the no-aggregation path too. The MAP header is bounds-checked first, since this path can receive a frame shorter than the header.(CVE-2026-64550)

In the Linux kernel, a use-after-free vulnerability exists in the SCTP ASCONF processing. sctpprocessasconf() caches the transport the ASCONF chunk is processed against in asconf->transport. For an ASCONF located through its Address Parameter by __sctprcvasconflookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctpprocessasconfparam() rejects a DEL-IP for the packet source address, but nothing protects asconf->transport. A single ASCONF can carry [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source, causing the freed transport to be dereferenced, potentially leading to system crash or code execution.(CVE-2026-64564)

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

ksmbd: defer destroyprevioussession() until after NTLM authentication

In ntlmauthenticate(), destroyprevioussession() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroyprevioussession() destroys the victim's session while ksmbddecodentlmsspauth_blob() subsequently rejects the request with -EPERM.

Move destroyprevioussession() and the previd assignment to after ksmbddecodentlmsspauthblob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5authenticate(), where destroyprevioussession() is called only after ksmbdkrb5authenticate() returns success.(CVE-2026-68130)

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

libceph: bound pg_{temp,upmap,upmapitems} length to CEPHPGMAXSIZE

__decodepgtemp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPHPGMAXSIZE. The helper backs both pgtemp and pgupmap decoding, and applyupmap()/gettemposds() later copy the decoded list into the fixed-size on-stack array struct cephosds.osds[CEPHPGMAXSIZE]. A monitor that sends an OSDMap with a pgtemp/pgupmap entry longer than 32 thus causes a stack out-of-bounds write.

An OSD set for a single PG can never exceed CEPHPGMAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against.

BUG: KASAN: stack-out-of-bounds in cephpgtoupactingosds Write of size 4 ... by task exploit kasanreport (mm/kasan/report.c:595) cephpgtoupactingosds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calctarget (net/ceph/osd_client.c:1638) __submitrequest (net/ceph/osdclient.c:2394) cephosdcstartrequest (net/ceph/osdclient.c:2490) cephosdccall (net/ceph/osdclient.c:5164) rbddevimageprobe (drivers/block/rbd.c:6899) dorbdadd (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670!

idryomov: do the same in _decodepgupmapitems()