CVE-2026-72250 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6 defrag
nf_ct_frag6_reasm() slides the packet head forward to drop the IPv6 fragment header and then unconditionally advances skb->mac_header:
skb->mac_header += sizeof(struct frag_hdr);
On the NF_INET_LOCAL_OUT defrag path the skb has no link-layer header yet, so skb->mac_header is still the "not set" sentinel (u16)~0U. Adding sizeof(struct frag_hdr) wraps it to a small value (0xffff + 8 == 7), after which skb_mac_header_was_set() wrongly reports a MAC header is present and skb_mac_header() points into the headroom.
The reassembler has done this unconditional add since it was introduced; it was harmless while mac_header was a bare pointer, but wrong once mac_header became a u16 offset whose unset state is the ~0U sentinel tested by skb_mac_header_was_set(). The sibling net/ipv6/reassembly.c does the same relocation and does guard the adjustment; mirror the guard here.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability exists within the Linux kernel's netfilter subsystem, specifically in the nf_conntrack_reasm module where IPv6 packet reassembly occurs. This flaw manifests in the nf_ct_frag6_reasm() function which processes fragmented IPv6 packets during connection tracking. The function manipulates packet headers by sliding the packet head forward to remove the IPv6 fragment header while simultaneously advancing the skb->mac_header pointer without proper conditional checks.
The technical implementation issue stems from an unconditional adjustment of the skb->mac_header field where sizeof(struct frag_hdr) is added regardless of whether a valid MAC header exists. When packets traverse the NF_INET_LOCAL_OUT defragmentation path, they lack link-layer headers entirely, leaving skb->mac_header set to the sentinel value ~0U indicating "not set." The subsequent arithmetic operation 0xffff + 8 = 7 causes the mac_header offset to wrap around to a small positive value, which incorrectly satisfies the skb_mac_header_was_set() check and leads to improper header pointer resolution.
This vulnerability represents a classic case of improper state management in kernel networking code, where legacy assumptions about data structure layouts no longer hold true with modern implementations. The original code was harmless when mac_header functioned as a simple pointer but became problematic once it transitioned to a u16 offset field with specific sentinel values for tracking unset states. The issue aligns with CWE-704 improper type conversion and CWE-129 insecure input validation patterns commonly found in kernel network subsystems.
The operational impact of this vulnerability allows for potential packet corruption, incorrect header parsing, and could enable attackers to manipulate packet processing flows within the connection tracking subsystem. Malicious actors could potentially exploit this condition to cause denial of service or bypass security controls that depend on proper MAC header detection. The vulnerability affects systems running Linux kernels with netfilter support and active IPv6 fragmentation handling, particularly those implementing connection tracking functionality.
Mitigation strategies include applying the kernel patch that mirrors the guard pattern used in the sibling net/ipv6/reassembly.c module, which properly checks whether mac_header is set before performing the adjustment. Organizations should prioritize updating to patched kernel versions and implementing network monitoring to detect anomalous packet processing behavior that might indicate exploitation attempts. The fix requires conditional logic that prevents the mac_header adjustment when it would result in an invalid offset value, ensuring proper handling of packets without link-layer headers during IPv6 defragmentation operations.
This vulnerability demonstrates the complexity of maintaining backward compatibility in kernel networking code where subtle changes in data structure implementations can introduce critical security flaws. The issue highlights the importance of thorough testing across different packet processing paths and proper validation of header state management in kernel modules that handle network packet reassembly. Similar patterns may exist in other kernel subsystems where header manipulation occurs without proper state validation, making this a valuable case study for kernel security hardening practices and ATT&CK framework considerations related to kernel exploitation techniques.