OESA-2026-3206

The Linux Kernel, the operating system core itself.

Security Fix(es):

Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)

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

inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP

Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous.

socket(AFINET, SOCKRAW, 255);

A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes.

inner = IP(src="192.168.2.1", dst="8.8.8.8", proto=255)/Raw("TEST") pkt = IP(src="192.168.1.1", dst="192.168.2.1")/ICMP(type=3, code=4, nexthopmtu=576)/inner

"man 7 raw" states:

A protocol of IPPROTORAW implies enabled IPHDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets.

Make sure we drop these malicious packets.(CVE-2026-46266)

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

tun: free page on buildskb failure in tunxdp_one()

When buildskb() fails in tunxdpone(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhostnetbuildxdp() allocated for the frame. As with the short-frame rejection path, tunsendmsg() discards the per-buffer error and still returns totallen, so vhosttxbatch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk.

Free the page before taking the error path, matching the putpage() the other error exits of tunxdp_one() already perform.(CVE-2026-46322)

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

ip6vti: set netnsimmutable on the fallback device.

john1988 and Noam Rathaus reported that vti6initnet() does not set the netnsimmutable flag on the per-netns fallback tunnel device (ip6vti0).

Other similar tunnel drivers (like ip6tunnel, sit, ip6gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.(CVE-2026-52909)

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

netfilter: nf_queue: hold bridge skb->dev while queued

brpassframeup() rewrites skb->dev from the ingress port to the bridge master before queueing bridge LOCALIN packets. NFQUEUE only holds references on state.in/out and bridge physdevs, so a queued bridge packet can retain a freed bridge master in skb->dev until reinjection.

When the verdict is reinjected later, brnetifreceive_skb() re-enters the receive path with skb->dev still pointing at the freed bridge master, triggering a use-after-free.

Store skb->dev in the queue entry, hold a reference on it for the queue lifetime, and use the saved device when dropping queued packets during NETDEV_DOWN handling.(CVE-2026-52912)

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

netfilter: ip6t_hbh: reject oversized option lists

struct ip6topts stores at most IP6TOPTSOPTSNR option descriptors, but hbhmt6_check() does not reject larger optsnr values supplied from userspace.

Validate optsnr in the rule setup path so only match data that fits the fixed-size opts array can be installed. This follows the existing xtables pattern of rejecting invalid user-provided counts in checkentry() and keeps the packet matching path unchanged.

struct ip6t_opts has a fixed opts[IP6T_OPTS_OPTSNR] array, where IP6T_OPTS_OPTSNR is 16, then off-by-one array access is possible:

[ 137.924693][ T8692] UBSAN: array-index-out-of-bounds in ../net/ipv6/netfilter/ip6t_hbh.c:110:29 [ 137.926167][ T8692] index 16 is out of range for type '__u16 [16]'(CVE-2026-52915)

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

netfilter: xt_policy: fix strict mode inbound policy matching

matchpolicyin() walks sec_path entries from the last transform to the first one, but strict policy matching needs to consume info->pol[] in the same forward order as the rule layout.

Derive the strict-match policy position from the number of transforms already consumed so that multi-element inbound rules are matched consistently.(CVE-2026-52920)

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

netfilter: ebtables: fix OOB read in compatmtwfrom_user

Luxiao Xu says:

The function compatmtwfromuser() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied matchsize/target_size.

When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN.

This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets.

AFAIU this is relevant for matches that need to go though match->compatfromuser() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace).

The ->compatfromuser() callbacks assume they can read compatsize bytes, so they need this extra check.

Based on an earlier patch from Luxiao Xu.(CVE-2026-52927)

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

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

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

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

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

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

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

ceph: fix a buffer leak in _cephsetxattr()

The old_blob in __cephsetxattr() can store ci->ixattrs.preallocblob value during the retry. However, it is never called the cephbufferput() for the oldblob object. This patch fixes the issue of the buffer leak.(CVE-2026-52962)

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

netfilter: nfnetlink_osf: fix out-of-bounds read on option matching

In nfosfmatch(), the nfosfhdrctx structure is initialized once and passed by reference to nfosfmatchone() for each fingerprint checked. During TCP option parsing, nfosfmatch_one() advances the shared ctx->optp pointer.

If a fingerprint perfectly matches, the function returns early without restoring ctx->optp to its initial state. If the user has configured NFOSFLOGLEVELALL, the loop continues to the next fingerprint. However, because ctx->optp was not restored, the next call to nfosfmatchone() starts parsing from the end of the options buffer. This causes subsequent matches to read garbage data and fail immediately, making it impossible to log more than one match or logging incorrect matches.

Instead of using a shared ctx->optp pointer, pass the context as a constant pointer and use a local pointer (optp) for TCP option traversal. This makes nfosfmatch_one() strictly stateless from the caller's perspective, ensuring every fingerprint check starts at the correct option offset.(CVE-2026-52999)

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

bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops

When a BPF sockops program accesses ctx fields with dstreg == srcreg, the SOCKOPSGETSK() and SOCKOPSGETFIELD() macros fail to zero the destination register in the !fullsock / !lockedtcp_sock path.

Both macros borrow a temporary register to check isfullsock / islockedtcpsock when dstreg == srcreg, because dstreg holds the ctx pointer. When the check is false (e.g., TCPNEWSYNRECV state with a requestsock), dstreg should be zeroed but is not, leaving the stale ctx pointer:

• SOCKOPSGETSK: dstreg retains the ctx pointer, passes NULL checks as PTRTOSOCKETORNULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpfskctotcp6sock().

• SOCKOPSGETFIELD: dstreg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer.

Fix both macros by: - Changing JMPA(1) to JMPA(2) in the fullsock path to skip the added instruction. - Adding BPFMOV64IMM(si->dstreg, 0) after the temp register restore in the !fullsock path, placed after the restore because dstreg == srcreg means we need srcreg intact to read ctx->temp.(CVE-2026-53078)

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

net: phy: clean the sfp upstream if phy probing fails

Sashiko reported that we don't call sfpbusdel_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events.

This issue existed before the generic phylib sfp support, back when drivers were calling physfpprobe themselves.(CVE-2026-53232)

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

Bluetooth: MGMT: validate advertising TLV before type checks

tlvdatais_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer.

A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data.

KASAN reported the following when a malformed MGMTOPADD_ADVERTISING request reached that path:

BUG: KASAN: vmalloc-out-of-bounds in tlvdataisvalid() Read of size 1 Call trace: tlvdataisvalid() addadvertising() hcimgmtcmd() hcisock_sendmsg()

Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].(CVE-2026-53255)

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

netfilter: nft_ct: bail out on template ct in get eval

I noticed this issue while looking at a historic syzbot report [1].

A rule like the one below is enough to trigger the bug:

table ip t {
    chain pre {
        type filter hook prerouting priority raw;
        ct zone set 1
        ct original saddr 1.2.3.4 accept
    }
}

The first expression attaches a per-cpu template ct via nftctsetzoneeval() (nfcttmplalloc -> kzalloc, tuple is all zero, nfctl3num(ct) == 0). The next expression then calls nftctgeteval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFTREG3215 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers.

Reject template ct at the eval entry and in nftctgetfasteval(), mirroring the check nftctseteval() already has. Additionally, bound the address copy in NFTCTSRC / NFTCTDST by priv->len instead of by nfctl3num(ct): nfctgettuple() zeroes the tuple before pkttotuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack.

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

nfsd: fix posix_acl leak on SETACL decode failure

nfsaclsvcdecodesetaclargs() and nfs3svcdecodesetaclargs() each call nfsstreamdecodeacl() twice, first for NFSACL and then for NFSDFACL. Each successful call transfers ownership of a freshly allocated posixacl into argp->aclaccess or argp->acldefault. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling.

ACLPROC2SETACL.pcrelease was wired to nfssvcreleaseattrstat and ACLPROC3SETACL.pcrelease was wired to nfs3svcreleasefhandle. Both only call fhput() and have no knowledge of the ACL fields on argp. The posixaclrelease() pairs sat at the out: labels inside nfsacldprocsetacl() and nfsd3procsetacl(), but svcprocess() skips pcfunc when pcdecode returns false, so that cleanup is unreachable on decode failure:

svc_process_common()
  pc_decode()                  /* decode_setaclargs: false */
  /* pc_func skipped */
  pc_release()                 /* fh_put only -- ACLs leaked */

The orphaned posix_acl is leaked for the lifetime of the server.

Fix by adding nfsaclsvcreleasesetacl() and nfs3svcreleasesetacl(), which release both argp->aclaccess and argp->acldefault in addition to fhput(), and wiring them as pcrelease for their respective SETACL procedures. pcrelease runs on every path svcprocess() takes after decode, including decode failure, so the posixaclrelease() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.(CVE-2026-53397)

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

USB: serial: mct_u232: fix missing interrupt-in transfer sanity check

Add the missing sanity check on the size of interrupt-in transfers to avoid parsing stale or uninitialised slab data (and leaking it to user space).(CVE-2026-63897)

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

USB: serial: cypress_m8: validate interrupt packet headers

cypressreadintcallback() parses the interrupt-in buffer according to the selected Cypress packet format. Format 1 has a two-byte status/count header and format 2 has a one-byte combined status/count header. The usb-serial core sizes the interrupt-in buffer from the endpoint descriptor's wMaxPacketSize, and successful interrupt transfers can complete short when URBSHORTNOTOK is not set.

Check that the completed packet contains the selected header before reading it. Malformed short reports are ignored and the interrupt URB is resubmitted through the existing retry path, preventing out-of-bounds header-byte reads.

KASAN report as below: KASAN slab-out-of-bounds in cypressreadintcallback+0x240/0x7f0 Read of size 1 Call trace: cypressreadintcallback() (drivers/usb/serial/cypress_m8.c:1009) __usbhcdgivebackurb() dummytimer()

johan: use constants in header length sanity checks

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:

usb: typec: tcpm/tcpcimaxim: validate header NDO against RXBYTE_CNT

A broken/malicious port can transmit a CRC-valid frame whose header advertises up to seven data objects but whose body carries fewer than that. Check for this, and rightfully reject the message, instead of reading from uninitialized stack memory.(CVE-2026-63959)

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:

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:

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:

xfs: resample the data fork mapping after cycling ILOCK

xfsreflinkfill_{cowhole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfsfindtrimcowextent, but we don't refresh the data fork mapping beforehand, which means that the xfsbmaptrimcow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared.

If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle.(CVE-2026-64600)