Description

In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: reject dev-bound programs bound to a different device cls_bpf_prog_from_efd() obtained a SCHED_CLS program via bpf_prog_get_type_dev() but never verified that a device-bound (offloaded) program's bound netdev matches the TC netdev the classifier is being attached to. This let a program loaded with prog_ifindex for device A be attached via cls_bpf + skip_sw to device B; deleting device A then destroyed the program's offload state while it was still attached to device B, triggering a netdevsim WARN (panic with panic_on_warn=1). Mirror the XDP attach path (net/core/dev.c) and reject the attach with -EINVAL when a dev-bound program's bound device does not match the target device.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-26T15:16:52.173Z",
  "pubdate": "2026-08-26T15:16:52.173Z",
  "executiveSummary": "A device-bound program validation vulnerability exists within the Linux kernel's cls_bpf classifier. The issue stems from an improper verification process when attaching offloaded eBPF programs to network interfaces.\nThe vulnerability allows a malicious or misconfigured user to attach an eBPF program, originally bound to one network device (device A), to a completely different network device (device B) using the skip_sw flag.\nThe primary security impact involves kernel-level instability. Specifically, if the original device (device A) is deleted, the kernel attempts to destroy the offload state of the program while it remains active on device B. This inconsistency triggers a kernel WARN condition, which results in a system panic if panic_on_warn is enabled, leading to a Denial of Service (DoS).\nExploitation requires local access with sufficient privileges to interact with the Traffic Control (TC) subsystem and load eBPF programs. This flaw highlights a critical failure in cross-device integrity checking within the networking subsystem.",
  "technicalDetails": "The vulnerability resides in net/sched/cls_bpf, specifically within the cls_bpf_prog_from_efd() function. The root cause is a lack of validation check between the netdev identified in a device-bound (offloaded) eBPF program and the actual target netdev to which the cls_bpf classifier is being attached.\nWhen a program is loaded using bpf_prog_get_type_dev(), it may be bound to a specific netdev. The kernel expects that if a program is offloaded (dev-bound), it should only be utilized by the hardware device associated with that binding. However, the existing implementation failed to enforce this mapping, allowing the attachment of the program to an arbitrary device if the skip_sw flag is employed.\nThe attack flow follows a predictable pattern: 1) The attacker loads an eBPF program bound to 'device A' via standard eBPF interface mechanisms. 2) The attacker attempts to attach this program to 'device B' using the TC cls_bpf classifier, bypassing the software-side validation (skip_sw). 3) The kernel successfully maps the program to the device B structure despite the mismatch. 4) The attacker triggers the removal or destruction of 'device A'.\nDuring the destruction of 'device A', the kernel subsystem responsible for the device-bound program attempts to clean up the associated offload resources. Because the program state is still referenced by the active 'device B' classifier, the kernel encounters an invalid state or null reference. In the case of netdevsim, this generates a WARN message, indicating an invalid state transition. If the host system is configured with kernel.panic_on_warn=1, the entire kernel halts, resulting in a system crash.\nThis vulnerability is essentially a logic error in resource management. By decoupling the lifecycle of the eBPF program from its assigned device, the system enters an undefined state. The lack of an explicit check—resembling the robust path implemented in net/core/dev.c for XDP—allows this lifecycle mismatch to persist until it manifests as a kernel panic during hardware tear-down operations."
}