CVE-2026-90083: net/sched: act_ife: Only operate on Ethernet frames
In the Linux kernel, the following vulnerability has been resolved:
net/sched: actife: Only operate on Ethernet frames
actife encapsulates/decapsulates the original Ethernet header and uses skb->dev->hardheaderlen as the length of that header. That is only correct for Ethernet devices: on a device where hardheaderlen does not match the L2 header that was actually pulled (PPP reports PPPHDRLEN while nothing is stripped on ingress), the ingress skbpush()/skbpull() use the wrong length and can hit skbunderpanic when headroom is tight.
IFE is Ethernet-only by design - it builds an outer ethhdr, rewrites hsource/hdest/hproto, and calls ethtypetrans() on decode - so instead of trying to make the offsets work for arbitrary link types, simply drop packets that do not carry an Ethernet header.
Checking skb->dev->type alone is not enough. We have to cater for a corner case where mirred can redirect an skb from a non-Ethernet device to an Ethernet one, and skb->dev then says nothing about the framing the skb actually has: an skb redirected from ppp0 reaches the target's ingress hook with maclen 0 and no Ethernet header at all. So at ingress also require maclen to be ETHHLEN. On egress maclen is not maintained, so the device type is all we have; a bogus redirect there yields a malformed frame rather than an out-of-bounds push, and it would be malformed with or without IFE.
That corner case is not theoretical - redirecting from ppp0 into a veth that has an ife encode action on its ingress hook panics without this patch:
skbuff: skbunderpanic: len:98 put:14 head:ffff88800e410000 data:ffff88800e40fff5 tail:0x57 end:0x640 dev:veth3 kernel BUG at net/core/skbuff.c:214! Call Trace: skbpush (net/core/skbuff.c:224 net/core/skbuff.c:2657) tcfifeact (net/sched/actife.c:829 net/sched/actife.c:874) tcrun (net/core/dev.c:4463) netifreceiveskb (net/core/dev.c:6463 net/core/dev.c:6522) tcfmirredtodev (net/sched/actmirred.c:248 net/sched/actmirred.c:328) tcfmirredact (net/sched/actmirred.c:489) tcrun (net/core/dev.c:4463) processbacklog (net/core/dev.c:6728)
With Ethernet framing guaranteed, use ETHHLEN instead of hardheaderlen.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux kernel (net/sched/act_ife)to a version that resolves this vulnerability.Patch net/sched: act_ife: Only operate on Ethernet frames - Configuration
Configure/ensure the act_ife egress/ingress behavior is Ethernet-only: it should require an Ethernet header and drop packets that do not carry an Ethernet header (use ETH_HLEN rather than mac_len/hard_header_len-derived values for Ethernet framing).
Linux kernel traffic control action act_ife Ethernet-only behavior = Only operate on Ethernet frames
Event History
Frequently Asked Questions
Which configurations are exposed to this issue?
Systems using the act_ife traffic-control action on ingress can be affected when packets are not actually Ethernet-framed. PPP is an example because its reported hard-header length can differ from the framing present on ingress.
Can redirected traffic trigger the problem even when the receiving device is Ethernet?
Yes. A mirred redirect can send an skb from a non-Ethernet device to an Ethernet device, making skb->dev->type appear Ethernet even though the packet has no Ethernet header. Such packets can reach ingress with mac_len set to 0.
What can be done if the fix cannot be deployed immediately?
Avoid applying act_ife to traffic from non-Ethernet interfaces, and avoid mirred redirect paths that send non-Ethernet-framed packets to an Ethernet device's ingress processing. Checking only the receiving device type is not sufficient to prevent this case.
What symptom may indicate this issue has been encountered?
The incorrect ingress skb_push() or skb_pull() length can trigger skb_under_panic when packet headroom is tight.