CVE-2026-90078: net/sched: act_skbmod: fix length calculations and avoid invalid header warnings
In the Linux kernel, the following vulnerability has been resolved:
net/sched: actskbmod: fix length calculations and avoid invalid header warnings
syzbot reported a warning in skbnetworkheaderlen() triggered by tcfskbmodact():
!skbtransportheaderwasset(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skbnetworkheaderlen include/linux/skbuff.h:3243 [inline] WARNING: CPU: 0 PID: 14949 at net/sched/actskbmod.c:55 tcfskbmodact+0xfe8/0x1810 net/sched/actskbmod.c:55
There are a few issues in tcfskbmodact():
1. Calling skbnetworkheaderlen() assumes skb->transportheader is set, which is not guaranteed when tcfskbmodact() runs at TC ingress. 2. Unconditionally calling skbmacheaderlen() at the beginning of tcfskbmodact() 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 skbensurewritable() 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 skbnetworkoffset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMODFECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == maclen). - Setting maxeditlen to ETHHLEN for Ethernet header modifications after validating ARPHRDETHER.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In tcf_skbmod_act(), avoid unconditionally calling skb_network_header_len() / skb_mac_header_len() in ways that assume skb->transport_header is set; instead calculate required header lengths correctly when skb->data points to the network header at TC ingress (including TUN/L3 cases) so skb_ensure_writable() is not asked for more bytes than the actual IP packet length.
Linux kernel (net/sched act_skbmod) tcf_skbmod_act() header length calculations = fix length calculations and avoid invalid header warnings - Configuration
On TC ingress where skb->data points to the network header, ensure MAC header state is set so MAC header length evaluation does not underflow/produce garbage length (the resolved issue: 'MAC header is unset, evaluating to an underflowed garbage length').
Linux kernel (TC ingress skbmod) MAC header handling = ensure MAC header is set before length evaluation - Configuration
Set max_edit_len to ETH_HLEN for Ethernet header modifications to prevent incorrect length handling.
Linux kernel (skb skbmod) max_edit_len = set to ETH_HLEN for Ethernet header modifications - Configuration
When computing offsets for packet header edits, use skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) rather than assumptions that can cause incorrect lengths (including the noted 28-byte UDP/IPv4 packet case).
Linux kernel (skb offsets) network offset usage for IP header offsets = use skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) (for 28-byte UDP/IPv4 packets)
Event History
Frequently Asked Questions
Which traffic paths are implicated by this issue?
The issue occurs when the skbmod traffic-control action runs at TC ingress. It is specifically relevant to packets on L3 devices such as TUN, where the MAC header may be unset, and to packets whose transport header is not set.
What operational impact can indicate that a system is affected?
Affected systems can emit warnings from skb_network_header_len() in tcf_skbmod_act(). They can also drop valid short ingress packets, including 28-byte UDP/IPv4 packets, because the writable-length calculation can exceed the actual IP packet length.
Is a MAC header required for the problem to occur?
No. The vulnerability includes an unconditional MAC-header length calculation that is unsafe on L3 devices where no MAC header is set. In that case, the calculated length can underflow and become garbage.