CVE-2026-74382

UnknownEPSS 0.19%

Last modified

CVE-2026-74382 is a vulnerability of currently unknown severity. 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. EPSS estimates a 0.19% chance of exploitation in the next 30 days.

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/ce5a6005-3c5e-4696-9e05-eba9461dc860@std.uestc.edu.cn/T/#u

Metrics

EPSS Probability
0.19%

9.5th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= 102740bd9436a3a6ba129af3a48271d794009fa5, < a018f208ab7512380bd4cf670064d48cba00a1b1; >= 102740bd9436a3a6ba129af3a48271d794009fa5, < 33373e1f378a501bc51aa73312f74295c84e3101; >= 102740bd9436a3a6ba129af3a48271d794009fa5, < e2d3b7bab3748c811dc5750ce9a8d62bc7f90ed7; >= 102740bd9436a3a6ba129af3a48271d794009fa5, < 4a76953c3ed043797e81529b9395e9ca6f4c7609; >= 102740bd9436a3a6ba129af3a48271d794009fa5, < 1387f252a242a51bfbb6eace29c8f8db21b457da; >= 102740bd9436a3a6ba129af3a48271d794009fa5, < 10753da2d659dd425a6e620f47f86852d604f67f; >= 102740bd9436a3a6ba129af3a48271d794009fa5, < 3fa6fb5d771c992ebedbfa7331c6bcc6f33f89b7; >= 102740bd9436a3a6ba129af3a48271d794009fa5, < 27db54b90bcc7c37867fe664107fa25ea6a116e4
LinuxLinux4.15

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-74382?
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/ce5a6005-3c5e-4696-9e05-eba9461dc860@std.uestc.edu.cn/T/#u
How severe is CVE-2026-74382?
Severity scoring for CVE-2026-74382 is pending analysis. The EPSS model estimates a 0.19% probability of exploitation in the next 30 days.
How do I fix CVE-2026-74382?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

Are you affected by CVE-2026-74382?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST