CVE-2026-72407 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
geneve: validate inner network offset in geneve_gro_complete()
Even with both paths gated on gs->gro_hint, geneve_gro_complete() re-derives the inner dispatch type and length from the packet and the current gs->gro_hint, independently of geneve_gro_receive(). The two can disagree if gs->gro_hint flips under a concurrent geneve_quiesce()/ geneve_unquiesce() (sk_user_data is NULL across a synchronize_net()), or if the re-read option bytes differ from the ones receive parsed.
geneve_gro_receive() already records the inner network header position in NAPI_GRO_CB()->inner_network_offset. Have geneve_gro_complete() compute the offset it is about to dispatch at, adding ETH_HLEN in the ETH_P_TEB case where eth_gro_complete() steps over the inner MAC header, and bail out if it lands past inner_network_offset.
Use a lower bound rather than exact equality: between gh_len and the inner L3 header, geneve_gro_receive() may also have pulled an inner VLAN tag (vlan_gro_receive() advances the recorded offset past it), which only moves inner_network_offset further out. A valid frame therefore always satisfies inner_nh <= inner_network_offset, while a gh_len inflated by a hint gro_receive() did not honour dispatches past the validated inner header, i.e. the out-of-bounds completion. Only the latter is rejected.
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 in question affects the Linux kernel's Generic Network Virtualization Encapsulation (GENEVE) implementation, specifically within the geneve_gro_complete() function. This issue represents a critical validation flaw that could potentially allow attackers to manipulate network packet processing through carefully crafted malformed packets. The problem stems from inconsistent handling of inner network header offsets between different stages of the GRO (Generic Receive Offload) processing pipeline, creating a potential vector for bypassing security checks and executing unauthorized operations.
The technical flaw manifests when geneve_gro_complete() independently re-derives the inner dispatch type and length from packet data without properly synchronizing with the values established during geneve_gro_receive(). This discrepancy occurs because both functions operate on the same gs->gro_hint value but process information independently, leading to potential inconsistencies. The vulnerability becomes particularly dangerous when concurrent geneve_quiesce() and geneve_unquiesce() operations occur, as these can cause sk_user_data to become NULL across synchronize_net() boundaries, resulting in divergent processing paths. Additionally, differences between option bytes read during re-processing versus those parsed during initial reception can create further inconsistencies in the packet header validation process.
The operational impact of this vulnerability extends beyond simple denial-of-service scenarios, potentially allowing for privilege escalation or arbitrary code execution within the kernel space. When the inner network header offset validation fails due to these inconsistencies, malicious actors could craft packets that appear valid to the initial parsing stage but trigger incorrect processing in the completion phase. The vulnerability specifically targets the GRO completion mechanism where packet headers are assembled and dispatched, making it particularly dangerous for high-throughput network environments where packet processing occurs rapidly. This type of issue aligns with CWE-129 Input Validation and can be categorized under ATT&CK technique T1068, which covers Local Privilege Escalation through kernel vulnerabilities.
The proposed mitigation strategy involves implementing proper offset validation within geneve_gro_complete() by computing the actual dispatch offset before processing, accounting for ETH_HLEN in the ETH_P_TEB case where eth_gro_complete() advances past inner MAC headers. The solution employs a lower bound comparison approach rather than strict equality checks, recognizing that geneve_gro_receive() may have pulled additional VLAN tags that advance the inner_network_offset position. This defensive programming approach acknowledges that legitimate frames will always satisfy the condition inner_nh <= inner_network_offset while specifically rejecting cases where the gh_len inflation from incorrect hint processing would dispatch past validated inner headers. The fix ensures that only out-of-bounds completions are rejected, preventing legitimate packet processing while maintaining security boundaries around the validated inner network header position.
The resolution addresses a fundamental race condition and synchronization issue within the kernel's network packet processing subsystem, demonstrating how seemingly minor inconsistencies in header offset validation can create significant security vulnerabilities. This vulnerability highlights the importance of proper synchronization mechanisms between different stages of packet processing and the necessity of maintaining consistent state information across concurrent operations. The fix reinforces the principle that kernel-level networking code must maintain strict validation boundaries, particularly when dealing with complex encapsulation protocols like GENEVE where multiple layers of header parsing occur simultaneously. The solution also emphasizes the need for defensive programming practices in kernel space where incorrect assumptions about packet structure can lead to serious security implications.
This vulnerability represents a classic example of how network protocol implementations must account for concurrent access patterns and ensure proper state synchronization between different processing stages. The fix demonstrates the importance of maintaining consistency in header offset calculations throughout the GRO pipeline, particularly when dealing with encapsulation protocols that may modify packet headers during processing. The implementation approach follows established security principles by using lower-bound validation rather than exact matching, which provides better resilience against subtle timing variations and concurrent access issues. This type of vulnerability underscores the critical nature of kernel security auditing and the importance of comprehensive testing for race conditions in network subsystems where multiple threads or processes may interact with shared packet processing state information.
The mitigation strategy specifically targets the root cause by ensuring that geneve_gro_complete() properly validates its assumptions about inner network header positions before proceeding with packet dispatch operations. This approach prevents maliciously crafted packets from exploiting the inconsistency between different parsing stages while maintaining legitimate packet processing functionality. The solution also incorporates lessons learned from similar vulnerabilities in other kernel networking components, emphasizing the need for consistent handling of VLAN tag processing and proper accounting for all header modifications that may occur during packet reception and processing.