critical CVSS 9.8

CVE-2026-64047·Kernel vulnerability

In the Linux kernel, the following vulnerability has been resolved: net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring When an sk_msg scatterlist ring wraps (sg.end < sg.start), tls_push_record() chains the tail portion of the ring to the head using sg_chain(). An extra entry in the sg array is reserved for this: struct sk_msg_sg { [...] /* 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[MAX_MSG_FRAGS + 2]; The current code uses MAX_SKB_FRAGS + 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 sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. = &data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 = data[start + (MAX_SKB_FRAGS - start + 1) - 1] = data[MAX_SKB_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).

Severity
critical
Software
Kernel
Fixed in
7.0.11
Published
2026-07-19

Affected versions

From: 6.19

Until: 7.0.11

Fixed in: 7.0.11

How to fix this CVE

Update your Linux kernel to version 7.0.11 or later to patch a critical scatterlist chain pointer miscalculation in the TLS subsystem. This vulnerability affects kernel versions 6.19 through 7.0.10 and can lead to memory corruption during TLS record processing. Apply the security update immediately through your distribution's package manager.

sudo dnf update kernel kernel-devel

Defensia detects this vulnerability

How to check if you are affected

  1. Check installed kernel version: uname -r (vulnerable if between 6.19 and 7.0.10)
  2. Verify TLS support is enabled: grep -i tls /boot/config-$(uname -r) (look for CONFIG_TLS=m or CONFIG_TLS=y)
  3. Monitor kernel logs for scatterlist corruption: dmesg | grep -i 'sg\|chain\|corruption' or journalctl -k | grep -i 'sg\|chain'
  4. Confirm patch applied after update: grep -i 'sk_msg.*sg_chain' /boot/config-$(uname -r) and verify kernel version >= 7.0.11 with uname -r

FAQ

What is CVE-2026-64047?

This is a critical kernel vulnerability in the TLS subsystem where an off-by-one error in scatterlist chain pointer placement causes memory corruption when the message ring buffer wraps. It affects kernel versions 6.19 through 7.0.10 and requires immediate patching.

Is CVE-2026-64047 being actively exploited?

No, this vulnerability is not currently listed on the CISA Known Exploited Vulnerabilities (KEV) catalog and no public exploits are available, though the critical CVSS score warrants urgent patching.

What versions of Kernel are affected by CVE-2026-64047?

Linux kernel versions 6.19 through 7.0.10 are vulnerable; upgrade to 7.0.11 or later to remediate.

How do I check if my server is vulnerable to CVE-2026-64047?

Run `uname -r` to display your kernel version. If it shows a version between 6.19 and 7.0.10, your system is vulnerable and requires immediate kernel update.

Does Defensia detect CVE-2026-64047?

Yes — Defensia's CVE advisory scanner compares installed package versions against the NVD database. If the Linux kernel is installed on a monitored server, CVE-2026-64047 will appear in your dashboard with remediation steps.

Related Kernel CVEs

CVE-2026-100075CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Fix srpt_alloc_rw_ctxs() unwind counters When srpt_alloc_rw_ctxs() fails partway through a multi-buffer indirect descriptor, the unwind path destroys RDMA contexts but leaves stale n_rw_ctx and n_rdma values (and a dangling rw_ctxs pointer). Later sq_wr_avail accounting in srpt_queue_response() or srpt_write_pending() can then subtract the wrong number of send queue credits. Reset the counters and clear rw_ctxs after freeing the heap allocation before returning an error.
CVE-2025-39682CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: tls: fix handling of zero-length records on the rx_list Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rx_list. Next recvmsg() will pick it up from there. Queuing the skb to rx_list after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length). Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rx_list, and it's zero length.
CVE-2026-64391CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for ADS I/O Alternate data streams are stored as xattrs. Unlike regular file I/O, their read and write paths therefore call VFS xattr helpers which recheck inode permissions and LSM policy using the current task credentials. Run ADS I/O with the credentials captured when the SMB handle was opened.
CVE-2025-38660CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: [ceph] parse_longname(): strrchr() expects NUL-terminated string ... and parse_longname() is not guaranteed that. That's the reason why it uses kmemdup_nul() to build the argument for kstrtou64(); the problem is, kstrtou64() is not the only thing that need it. Just get a NUL-terminated copy of the entire thing and be done with that...
CVE-2026-64397CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: ksmbd: serialize QUERY_DIRECTORY requests per file smb2_query_dir() stores a pointer to its stack-allocated private data in the ksmbd_file readdir_data. Concurrent QUERY_DIRECTORY requests using the same file handle can overwrite this pointer while an iterate_dir() callback is still using it, resulting in a stack use-after-free. Add a per-file mutex and hold it while accessing the shared directory enumeration state. The lock covers scan restart, dot entry state, readdir_data setup and iteration, and response construction. This prevents another request from replacing readdir_data.private before the current request has finished using it and also serializes the shared file position.

References

Track CVEs across your fleet automatically

Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2026-64047. Free for 1 server.

Get started free