Answer in brief
CVE-2026-90083 records a Unknown severity vulnerability in net/sched: act_ife: Only operate on Ethernet frames. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=295a6e06d21e1f469c9f38b00125a13b60ad4e7c <d218ea7df6eba076171f2d4897a429a31f2139f0 || >=295a6e06d21e1f469c9f38b00125a13b60ad4e7c <138b0054021fd7d57bc3eb68b3f4e2bcec037849 || >=295a6e06d21e1f469c9f38b00125a13b60ad4e7c <5b483f7791b079bb97d411f1066652ff659207ff | d218ea7df6eba076171f2d4897a429a31f2139f0, 138b0054021fd7d57bc3eb68b3f4e2bcec037849, 5b483f7791b079bb97d411f1066652ff659207ff |
| Linux/Linuxgeneric | 4.11 | Not reported |
| Linux/Linuxgeneric | >=295a6e06d21e1f469c9f38b00125a13b60ad4e7c <b951dd2fd5ede007474fc134ecb5639e1f86f5de || >=295a6e06d21e1f469c9f38b00125a13b60ad4e7c <13dddf87a1f89557920f9b437a21ea0b7225f828 || >=295a6e06d21e1f469c9f38b00125a13b60ad4e7c <d218ea7df6eba076171f2d4897a429a31f2139f0 || >=295a6e06d21e1f469c9f38b00125a13b60ad4e7c <138b0054021fd7d57bc3eb68b3f4e2bcec037849 || >=295a6e06d21e1f469c9f38b00125a13b60ad4e7c <5b483f7791b079bb97d411f1066652ff659207ff | b951dd2fd5ede007474fc134ecb5639e1f86f5de, 13dddf87a1f89557920f9b437a21ea0b7225f828, d218ea7df6eba076171f2d4897a429a31f2139f0, 138b0054021fd7d57bc3eb68b3f4e2bcec037849, 5b483f7791b079bb97d411f1066652ff659207ff |
| Linux/Linuxgeneric | >=295a6e06d21e1f469c9f38b00125a13b60ad4e7c <3c07621770b04f19b67e3af4a24b4d447826fbdd || >=295a6e06d21e1f469c9f38b00125a13b60ad4e7c <b951dd2fd5ede007474fc134ecb5639e1f86f5de || >=295a6e06d21e1f469c9f38b00125a13b60ad4e7c <13dddf87a1f89557920f9b437a21ea0b7225f828 || >=295a6e06d21e1f469c9f38b00125a13b60ad4e7c <d218ea7df6eba076171f2d4897a429a31f2139f0 || >=295a6e06d21e1f469c9f38b00125a13b60ad4e7c <138b0054021fd7d57bc3eb68b3f4e2bcec037849 || >=295a6e06d21e1f469c9f38b00125a13b60ad4e7c <5b483f7791b079bb97d411f1066652ff659207ff | 3c07621770b04f19b67e3af4a24b4d447826fbdd, b951dd2fd5ede007474fc134ecb5639e1f86f5de, 13dddf87a1f89557920f9b437a21ea0b7225f828, d218ea7df6eba076171f2d4897a429a31f2139f0, 138b0054021fd7d57bc3eb68b3f4e2bcec037849, 5b483f7791b079bb97d411f1066652ff659207ff |
Published upstream
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 30, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 17, 2026
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ife: Only operate on Ethernet frames act_ife encapsulates/decapsulates the original Ethernet header and uses skb->dev->hard_header_len as the length of that header. That is only correct for Ethernet devices: on a device where hard_header_len does not match the L2 header that was actually pulled (PPP reports PPP_HDRLEN while nothing is stripped on ingress), the ingress skb_push()/skb_pull() use the wrong length and can hit skb_under_panic when headroom is tight. IFE is Ethernet-only by design - it builds an outer ethhdr, rewrites h_source/h_dest/h_proto, and calls eth_type_trans() 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 mac_len 0 and no Ethernet header at all. So at ingress also require mac_len to be ETH_HLEN. On egress mac_len 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: skb_under_panic: len:98 put:14 head:ffff88800e410000 data:ffff88800e40fff5 tail:0x57 end:0x640 dev:veth3 kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:224 net/core/skbuff.c:2657) tcf_ife_act (net/sched/act_ife.c:829 net/sched/act_ife.c:874) tc_run (net/core/dev.c:4463) netif_receive_skb (net/core/dev.c:6463 net/core/dev.c:6522) tcf_mirred_to_dev (net/sched/act_mirred.c:248 net/sched/act_mirred.c:328) tcf_mirred_act (net/sched/act_mirred.c:489) tc_run (net/core/dev.c:4463) process_backlog (net/core/dev.c:6728) With Ethernet framing guaranteed, use ETH_HLEN instead of hard_header_len.
Quoted source text, attributed separately from HOL analysis.