critical CVSS 9.8

CVE-2026-43501·Kernel vulnerability

In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: reserve mac_len headroom when recompressed SRH grows ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: skb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards.

Severity
critical
Software
Kernel
Fixed in
7.0.4
Published
2026-05-21

Affected versions

From: 6.19

Until: 7.0.4

Fixed in: 7.0.4

How to fix this CVE

Update your Linux kernel to version 7.0.4 or later to patch a critical memory corruption vulnerability in IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) header processing. This vulnerability allows unauthenticated remote attackers to trigger out-of-bounds memory writes through specially crafted IPv6 packets with type-3 Source Routing Headers. Immediate patching is strongly recommended for all systems, particularly those processing IPv6 traffic or running network services.

sudo dnf update kernel kernel-devel

Defensia detects this vulnerability

How to check if you are affected

  1. Check current kernel version: uname -r; if output is between 6.19 and 7.0.3, the system is vulnerable
  2. Verify IPv6 is enabled: cat /proc/sys/net/ipv6/conf/all/disable_ipv6; a value of 0 indicates IPv6 is active and the vulnerability surface exists
  3. Search kernel logs for RPL-related errors: journalctl -b | grep -i 'rpl\|srh\|routing'; look for memory access violations or oops messages
  4. Confirm patched kernel is installed: uname -r should show 7.0.4 or later; verify with grep 'rpl_srh' /boot/config-$(uname -r) to ensure RPL code is compiled in

FAQ

What is CVE-2026-43501?

CVE-2026-43501 is a critical kernel vulnerability in IPv6 RPL header processing where insufficient headroom validation during Source Routing Header recompression allows remote attackers to write memory outside allocated buffer boundaries, potentially causing kernel crashes or arbitrary code execution.

Is CVE-2026-43501 being actively exploited?

No. This vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog and no public exploits are currently available, though the critical severity warrants urgent patching.

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

Linux kernel versions 6.19 through 7.0.3 are vulnerable. Version 7.0.4 and later contain the fix.

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

Run 'uname -r' and compare the output against the vulnerable range (6.19 to 7.0.3). If your kernel version falls within this range, your system is vulnerable.

Does Defensia detect CVE-2026-43501?

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-43501 will appear in your dashboard with remediation steps.

Related Kernel CVEs

CVE-2026-64439CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: crypto: krb5 - filter out async aead implementations at alloc krb5_aead_encrypt(), krb5_aead_decrypt() in rfc3961_simplified.c and rfc8009_encrypt(), rfc8009_decrypt() in rfc8009_aes2.c set a NULL completion callback and treat any negative return from crypto_aead_{encrypt,decrypt}() as terminal, falling through to kfree_sensitive(buffer). When the encrypt_name resolves to an async AEAD instance the request returns -EINPROGRESS, the buffer is freed while the backend's worker still holds a pointer, and the worker dereferences the freed slab on completion. KASAN report under UML+SLUB with a synthetic async aead backend bound to krb5->encrypt_name: BUG: KASAN: slab-use-after-free in t5_stub_complete+0x7d/0xc7 The helpers were written synchronously, so filter the async instances out at allocation time instead of plumbing crypto_wait_req() through every call site. Reachable via net/rxrpc/rxgk.c, fs/afs/cm_security.c and net/ceph/crypto.c on systems with an async AEAD provider bound to the krb5 enctype name.
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-2026-64056CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Make RX SKB per-port The SKB used to assemble packets from fragments in gmac_rx() is static local, but the Gemini has two ethernet ports, meaning there can be races between the ports on a bad day if a device is using both. Make the RX SKB a per-port variable and carry it over between invocations in the port struct instead. Zero the pointer once we call napi_gro_frags(), on error (after calling napi_free_frags()) or if the port is stopped. Zero it in some place where not strictly necessary just to emphasize what is going on. This was found by Sashiko during normal patch review.
CVE-2026-64066CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_read_to_pagecache() to pause on subreq failure Fix netfs_read_to_pagecache() so that it pauses the generation of new subrequests if an already-issued subrequest fails.
CVE-2026-64061CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: netfs: Fix early put of sink folio in netfs_read_gaps() Fix netfs_read_gaps() to release the sink page it uses after waiting for the request to complete. The way the sink page is used is that an ITER_BVEC-class iterator is created that has the gaps from the target folio at either end, but has the sink page tiled over the middle so that a single read op can fill in both gaps. The bug was found by KASAN detecting a UAF on the generic/075 xfstest in the cifsd kernel thread that handles reception of data from the TCP socket: BUG: KASAN: use-after-free in _copy_to_iter+0x48a/0xa20 Write of size 885 at addr ffff888107f92000 by task cifsd/1285 CPU: 2 UID: 0 PID: 1285 Comm: cifsd Not tainted 7.0.0 #6 PREEMPT(lazy) Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x17f/0x4f1 kasan_report+0x100/0x1e0 kasan_check_range+0x10f/0x1e0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x48a/0xa20 __skb_datagram_iter+0x2c9/0x430 skb_copy_datagram_iter+0x6e/0x160 tcp_recvmsg_locked+0xce0/0x1130 tcp_recvmsg+0xeb/0x300 inet_recvmsg+0xcf/0x3a0 sock_recvmsg+0xea/0x100 cifs_readv_from_socket+0x3a6/0x4d0 [cifs] cifs_read_iter_from_socket+0xdd/0x130 [cifs] cifs_readv_receive+0xaad/0xb10 [cifs] cifs_demultiplex_thread+0x1148/0x1740 [cifs] kthread+0x1cf/0x210

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-43501. Free for 1 server.

Get started free