CVE-2026-90078 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_skbmod: fix length calculations and avoid invalid header warnings
syzbot reported a warning in skb_network_header_len() triggered by tcf_skbmod_act():
!skb_transport_header_was_set(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline]
WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55
There are a few issues in tcf_skbmod_act():
1. Calling skb_network_header_len() assumes skb->transport_header is set, which is not guaranteed when tcf_skbmod_act() runs at TC ingress. 2. Unconditionally calling skb_mac_header_len() at the beginning of tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the MAC header is unset, evaluating to an underflowed garbage length. 3. On TC ingress, skb->data points to the network header. Adding the MAC header length to the IP header length causes skb_ensure_writable() to request more bytes than the actual IP packet length, dropping valid short packets (e.g. 28-byte UDP/IPv4 packets).
Fix these by: - Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMOD_F_ECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == mac_len). - Setting max_edit_len to ETH_HLEN for Ethernet header modifications after validating ARPHRD_ETHER.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel vulnerability in net/sched/act_skbmod.c represents a critical flaw in the handling of socket buffer headers during traffic control operations, specifically within the tcf_skbmod_act function. This issue was identified by syzbot and manifests as invalid header warnings triggered when accessing network transport layer information without proper initialization checks. The core technical deficiency lies in the assumption that certain packet metadata fields are consistently populated across different networking contexts. When this code path executes at the traffic control ingress point, it incorrectly presumes that the transport header offset has been established within the socket buffer structure. This presumption is unsafe because incoming packets may not have fully parsed headers depending on their origin and processing stage, leading to potential kernel warnings or undefined behavior when functions like skb_network_header_len are invoked without verifying that the necessary header pointers are valid.
A secondary aspect of this vulnerability involves the unconditional calculation of MAC header length at the start of the operation. On Layer 3 devices such as TUN interfaces where no Ethernet framing exists, attempting to retrieve the MAC header length results in an underflowed garbage value rather than a zero or appropriate default. This erroneous length calculation propagates through subsequent logic, causing significant operational disruptions. Specifically, when modifying packet headers for ECN marking purposes, the code adds this invalid MAC header length to the IP header length. This miscalculation causes skb_ensure_writable to request more bytes than are actually present in the valid IP packet payload. Consequently, legitimate short packets, such as 28-byte UDP over IPv4 datagrams that should be processed normally, are incorrectly dropped by the kernel due to perceived insufficient buffer space.
From a classification perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound and CWE-20 Improper Input Validation, as the code fails to validate assumptions about packet structure before performing arithmetic operations on header offsets. In terms of ATT&CK mapping, while not an exploit vector for external attackers directly, it relates to T1496 Resource Hijacking via Denial of Service if triggered in a high-volume traffic environment, potentially causing service degradation by dropping valid packets or generating excessive kernel warnings that impact system performance. The flaw highlights the complexity of maintaining state consistency across different network stack layers and device types within the Linux networking subsystem.
To mitigate this vulnerability, developers must ensure that header offset calculations are context-aware rather than assuming a fixed packet structure. For ECN modifications, using skb_network_offset combined with the size of IP or IPv6 headers ensures correct length calculation regardless of whether the operation occurs at ingress where offsets may be zero or egress where MAC lengths apply. Additionally, implementing strict validation for ARPHRD_ETHER before applying Ethernet header modifications prevents invalid operations on non-Ethernet devices like TUN interfaces. Setting max_edit_len to ETH_HLEN only after confirming the device type is an ether interface ensures that buffer management functions receive accurate length parameters. These changes prevent the dropping of valid short packets and eliminate the generation of spurious kernel warnings, thereby restoring robust packet processing behavior across diverse network configurations.