Description
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.
Published: 2026-09-17
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Memory corruption that can trigger a kernel panic and deny service
Action: Immediate Patch
AI Analysis

Impact

The vulnerability resides in the traffic‑control action act_ife within the Linux kernel. It incorrectly assumes every socket buffer carries an Ethernet header by using skb->dev->hard_header_len, which is only valid for Ethernet devices. When packets come from non‑Ethernet interfaces such as PPP, the header length used is wrong, leading skb_push and skb_pull to touch the buffer with an invalid offset. This can invoke skb_under_panic and crash the kernel, causing a denial‑of‑service and potentially corrupting kernel memory. The impact is a kernel panic and the loss of service for the affected host.

Affected Systems

The flaw is present in all Linux kernel builds that include the act_ife action before the patch was merged. The vendors list indicates the Linux kernel, and the affected product is the kernel as a whole. No explicit version range is published, so any kernel prior to the commit that logs the specific changes in the referenced URLs is vulnerable. Updating to the latest kernel that incorporates this commit removes the issue.

Risk and Exploitability

The EPSS score is below 1% and the flaw is not present in the CISA KEV catalog, indicating a low probability of exploitation. Nevertheless, the severity is high—the bug can be triggered by sending traffic that is redirected from a non‑Ethernet interface to a device employing act_ife. An attacker with the ability to inject packets or control mirred redirection is sufficient to cause a kernel panic. Because the potential impact is catastrophic and the exploit requires only a crafted packet, the prudent response is to apply the patch immediately, as the risk of damage outweighs the very low likelihood of exploitation.

Generated by OpenCVE AI on September 20, 2026 at 03:44 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that contains the act_ife patch. Refer to the commit URLs when verifying the update.
  • If possible, disable or restrict mirred redirection from non‑Ethernet devices to interfaces that use act_ife, or ensure that only Ethernet frames are processed by the action by validating the MAC length before applying the encode.
  • Add monitoring for kernel BUG or skb_under_panic messages in system logs and configure alerts so that any unintended kernel panic is reported promptly.

Generated by OpenCVE AI on September 20, 2026 at 03:44 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 20 Sep 2026 04:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119

Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
Description 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.
Title net/sched: act_ife: Only operate on Ethernet frames
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-17T16:06:00.185Z

Reserved: 2026-09-11T19:38:34.785Z

Link: CVE-2026-90083

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:16:57.707

Modified: 2026-09-17T17:16:57.707

Link: CVE-2026-90083

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-20T03:45:12Z

Weaknesses
  • CWE-119

    Improper Restriction of Operations within the Bounds of a Memory Buffer