Cloudanix VulnDB

CVE-2025-68815

None

CVSS

—

EPSS

0.2%

Published

Jan 13, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A bug in the Linux kernel's network traffic scheduler can let local users crash the whole system by repeatedly changing how traffic classes are prioritized.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The ets qdisc fails to remove a DRR class from the active list when it is reconfigured as strict via tc qdisc change, allowing the class to be added twice on subsequent reconfiguration and triggering list corruption (double-add) that can panic the kernel under list debugging.

Why it matters to the business

Unprivileged or locally authenticated users can trigger kernel crashes on systems using the ets scheduler, leading to denial of service, service restarts, or potential privilege escalation on affected Linux kernels; high ecosystem prevalence increases exposure for servers, routers, and containers.

How an attack unfolds

An attacker with sufficient privileges to issue tc qdisc change commands on an interface using ets first creates a mixed strict/DRR hierarchy, sends traffic to activate classes, then toggles a class between strict and DRR modes to cause a double-add on the active list, resulting in a kernel warning or panic.

How to fix it

Upgrade to a fixed kernel version containing commit 58fdce6bc005e964f1dbc3ca716f5fe0f68839a2 (or 5.10.248 and later stable releases). Rebuild and reboot with the patched kernel; avoid manual ets qdisc reconfiguration on unpatched systems until upgraded.

How to confirm the fix worked

Confirm the running kernel contains the fix by checking git commit or version string; reproduce the original tc sequence under list debugging and verify absence of the double-add warning; monitor for the ets_qdisc_change path in kernel traces.

Typical attack path

  1. Obtain local or container access allowing netlink/tc operations
  2. Add an ets qdisc with mixed strict and DRR bands
  3. Attach child qdiscs and filters to populate the active list
  4. Issue tc qdisc change commands that flip a DRR class to strict then back
  5. Trigger traffic or further reconfiguration to exercise the corrupted list
  6. Observe kernel oops or panic from list_add double-add

How to detect it

Search kernel logs for 'list_add double add' warnings originating from __list_add_valid_or_report called via ets_qdisc_change; inspect auditd or syslog for sequences of tc qdisc change commands on interfaces using ets; review netlink messages for repeated ets band reconfigurations.

  • list_add double add: new=
  • ets_qdisc_change
  • WARNING: CPU:.*PID:.*at lib/list_debug.c
  • tc qdisc change dev .* root handle .* ets bands .* strict

What your security team should do

  • Prioritize patching all systems using ets qdisc to the versions listed in fixed_versions within the next maintenance window
  • Restrict unprivileged use of tc and netlink operations via SELinux/AppArmor or capabilities
  • Audit for ets qdisc usage in container and host networking configurations
  • Enable kernel list debugging in test environments to surface similar issues early

The record

In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: Remove drr class from the active list if it changes to strict Whenever a user issues an ets qdisc change command, transforming a drr class into a strict one, the ets code isn't checking whether that class was in the active list and removing it. This means that, if a user changes a strict class (which was in the active list) back to a drr one, that class will be added twice to the active list [1]. Doing so with the following commands: tc qdisc add dev lo root handle 1: ets bands 2 strict 1 tc qdisc add dev lo parent 1:2 handle 20: \ tbf rate 8bit burst 100b latency 1s tc filter add dev lo parent 1: basic classid 1:2 ping -c1 -W0.01 -s 56 127.0.0.1 tc qdisc change dev lo root handle 1: ets bands 2 strict 2 tc qdisc change dev lo root handle 1: ets bands 2 strict 1 ping -c1 -W0.01 -s 56 127.0.0.1 Will trigger the following splat with list debug turned on: [ 59.279014][ T365] ------------[ cut here ]------------ [ 59.279452][ T365] list_add double add: new=ffff88801d60e350, prev=ffff88801d60e350, next=ffff88801d60e2c0. [ 59.280153][ T365] WARNING: CPU: 3 PID: 365 at lib/list_debug.c:35 __list_add_valid_or_report+0x17f/0x220 [ 59.280860][ T365] Modules linked in: [ 59.281165][ T365] CPU: 3 UID: 0 PID: 365 Comm: tc Not tainted 6.18.0-rc7-00105-g7e9f13163c13-dirty #239 PREEMPT(voluntary) [ 59.281977][ T365] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 59.282391][ T365] RIP: 0010:__list_add_valid_or_report+0x17f/0x220 [ 59.282842][ T365] Code: 89 c6 e8 d4 b7 0d ff 90 0f 0b 90 90 31 c0 e9 31 ff ff ff 90 48 c7 c7 e0 a0 22 9f 48 89 f2 48 89 c1 4c 89 c6 e8 b2 b7 0d ff 90 <0f> 0b 90 90 31 c0 e9 0f ff ff ff 48 89 f7 48 89 44 24 10 4c 89 44 ... [ 59.288812][ T365] Call Trace: [ 59.289056][ T365] <TASK> [ 59.289224][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.289546][ T365] ets_qdisc_change+0xd2b/0x1e80 [ 59.289891][ T365] ? __lock_acquire+0x7e7/0x1be0 [ 59.290223][ T365] ? __pfx_ets_qdisc_change+0x10/0x10 [ 59.290546][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.290898][ T365] ? __mutex_trylock_common+0xda/0x240 [ 59.291228][ T365] ? __pfx___mutex_trylock_common+0x10/0x10 [ 59.291655][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.291993][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.292313][ T365] ? trace_contention_end+0xc8/0x110 [ 59.292656][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.293022][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.293351][ T365] tc_modify_qdisc+0x63a/0x1cf0 Fix this by always checking and removing an ets class from the active list when changing it to strict. [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/net/sched/sch_ets.c?id=ce052b9402e461a9aded599f5b47e76bc727f7de#n663

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 0 5.10.248
Mageia:9 kernel 0 6.6.120-1.mga9
Mageia:9 kernel-linus 0 6.6.120-1.mga9
Mageia:9 kmod-virtualbox 0 7.1.14-14.mga9
Mageia:9 kmod-xtables-addons 0 3.24-88.mga9
openSUSE:Leap 16.0 dtb-aarch64 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-64kb 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-azure 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-default 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-default-base 0 6.12.0-160000.26.1.160000.2.7
openSUSE:Leap 16.0 kernel-docs 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-kvmsmall 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-obs-build 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-obs-qa 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-rt 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-source 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-syms 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-zfcpdump 0 6.12.0-160000.26.1

Related vulnerabilities