CVE-2026-74382

net/sched: cls_bpf: prevent unbounded recursion in offload rollback

N/A
Published: August 15, 2026 at 05:58 AM UTC
Updated: August 17, 2026 at 06:19 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: prevent unbounded recursion in offload rollback Quan Sun reported [1] a stack overflow in cls_bpf_offload_cmd(). Reproducer on netdevsim: add a skip_sw cls_bpf filter, set the bpf_tc_accept debugfs knob to 0, then `tc filter replace`. The replace calls tc_setup_cb_replace() which fails. cls_bpf_offload_cmd() then swaps prog/oldprog and recursively calls itself to roll back. But bpf_tc_accept=0 makes the rollback fail too, which triggers yet another rollback frame with the same arguments, and so on until the stack is exhausted. bpf_tc_accept is just a convenient knob for the reproducer. Any driver whose tc_setup_cb_replace() fails twice in a row can hit the same loop, so this is not a netdevsim-only issue. Two ways to fix it: 1) Have the rollback call tc_setup_cb_add() on oldprog instead of re-entering cls_bpf_offload_cmd(). 2) Mark the rollback frame with a flag and skip a second-level rollback from inside it. Go with (2). It is the smaller change and keeps the original behaviour: the rollback still goes through tc_setup_cb_replace(), so the driver gets one real chance to restore its state. If that attempt also fails, we just return the original error instead of recursing. [1]: https://lore.kernel.org/bpf/[email protected]/T/#u

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

4.15 ≤ v < 5.10.2614.15 ≤ v < 5.15.2124.15 ≤ v < 6.1.1784.15 ≤ v < 6.12.974.15 ≤ v < 6.18.404.15 ≤ v < 6.6.1454.15 ≤ v < 7.1.54.15 ≤ v < 7.2102740bd9436a3a6ba129af3a48271d794009fa54.15
Vendor states this is fixed in 10753da2d659dd425a6e620f47f86852d604f67f (fixed)
Vendor states this is fixed in 1387f252a242a51bfbb6eace29c8f8db21b457da (fixed)
Vendor states this is fixed in 27db54b90bcc7c37867fe664107fa25ea6a116e4 (fixed)
Vendor states this is fixed in 33373e1f378a501bc51aa73312f74295c84e3101 (fixed)
Vendor states this is fixed in 3fa6fb5d771c992ebedbfa7331c6bcc6f33f89b7 (fixed)
Vendor states this is fixed in 4a76953c3ed043797e81529b9395e9ca6f4c7609 (fixed)
Vendor states this is fixed in a018f208ab7512380bd4cf670064d48cba00a1b1 (fixed)
Vendor states this is fixed in e2d3b7bab3748c811dc5750ce9a8d62bc7f90ed7 (fixed)
Vendor states this is fixed in 4.15 (unaffected)
Vendor states this is fixed in 5.10.261 (unaffected)
Vendor states this is fixed in 5.15.212 (unaffected)
Vendor states this is fixed in 6.1.178 (unaffected)
Vendor states this is fixed in 6.12.97 (unaffected)
Vendor states this is fixed in 6.18.40 (unaffected)
Vendor states this is fixed in 6.6.145 (unaffected)
Vendor states this is fixed in 7.1.5 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card