CVE-2026-23379 Overview
A divide-by-zero vulnerability has been identified in the Linux kernel's network scheduler ETS (Enhanced Transmission Selection) qdisc implementation. The flaw exists in the offload path where computing each class' Weighted Round Robin (WRR) weight can result in an integer overflow condition, subsequently triggering a division by zero error and causing a kernel panic.
Critical Impact
This vulnerability can cause a complete system crash (kernel panic) when an attacker triggers the integer overflow condition in the ETS scheduler's offload path, resulting in denial of service.
Affected Products
- Linux Kernel with sch_ets module enabled
- Systems utilizing ETS (Enhanced Transmission Selection) network scheduling
- Network devices with hardware offloading capabilities using ETS qdisc
Discovery Timeline
- March 25, 2026 - CVE-2026-23379 published to NVD
- March 25, 2026 - Last updated in NVD database
Technical Details for CVE-2026-23379
Vulnerability Analysis
The vulnerability resides in the ets_offload_change() function within the sch_ets kernel module. When offloading ETS scheduling to hardware, the kernel computes each traffic class's WRR weight by averaging over the sums of quanta using variables q_sum and q_psum. These variables were implemented as unsigned int type, matching the size of individual DRR (Deficit Round Robin) quanta values.
The fundamental issue is that when multiple quanta values are summed, the accumulated value can exceed the maximum representable value for an unsigned 32-bit integer (4,294,967,295), causing the sum to wrap around to zero or a small positive number. When this overflowed value is subsequently used as a divisor in the WRR weight calculation, a divide-by-zero exception occurs, triggering a kernel panic.
The crash trace reveals the exact location: RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] with the error code indicating a divide error (Oops: divide error: 0000).
Root Cause
The root cause is the use of 32-bit unsigned integers (unsigned int) for accumulating quantum sums in the ETS offload calculation. When processing multiple ETS classes with large quantum values, the accumulated sum can overflow the 32-bit boundary. This integer overflow vulnerability results in either a wrapped-around small value or zero, which when used as a divisor causes the division-by-zero exception.
The fix involves changing the q_sum and q_psum variables from 32-bit to 64-bit integers, providing sufficient capacity to accumulate quantum sums without overflow risk.
Attack Vector
An attacker with sufficient privileges to configure network Quality of Service (QoS) settings can exploit this vulnerability by crafting ETS qdisc configurations with carefully chosen quantum values. When the tc (traffic control) utility is used to create or modify an ETS qdisc with parameters that cause the quantum sum to overflow, the kernel attempts to offload this configuration to hardware, triggering the vulnerable code path.
The attack chain involves:
- Attacker configures multiple ETS traffic classes with large quantum values
- The kernel's tc_modify_qdisc() function processes the configuration
- ets_qdisc_change() is called to apply the changes
- ets_offload_change() calculates WRR weights with overflowed sum
- Division by zero occurs, triggering kernel panic
The crash trace shows the complete call path through netlink_sendmsg → tc_modify_qdisc → ets_qdisc_change → ets_offload_change, confirming exploitation via the standard tc netlink interface.
Detection Methods for CVE-2026-23379
Indicators of Compromise
- Kernel crash logs (dmesg) showing divide error: 0000 with RIP pointing to ets_offload_change in sch_ets module
- System crashes or unexpected reboots when modifying network QoS configurations
- Kernel panic messages referencing sch_ets module in the call trace
Detection Strategies
- Monitor system logs for kernel oops messages containing references to sch_ets or ets_offload_change
- Implement kernel crash dump analysis to identify divide-by-zero exceptions in network scheduler code
- Deploy kernel module loading auditing to track sch_ets module usage
Monitoring Recommendations
- Enable crash dump collection (kdump) to capture kernel state during panics for forensic analysis
- Configure syslog alerting for kernel panic and oops messages
- Monitor tc command usage, particularly ETS qdisc configuration changes with unusually large quantum values
- Implement auditd rules to track netlink socket operations related to traffic control
How to Mitigate CVE-2026-23379
Immediate Actions Required
- Apply the kernel patches from the official kernel.org stable branches immediately
- If patching is not immediately possible, consider unloading the sch_ets module using modprobe -r sch_ets if ETS scheduling is not required
- Restrict access to network QoS configuration capabilities to trusted administrators only
- Monitor systems for any unusual network scheduler configuration attempts
Patch Information
The vulnerability has been fixed in multiple kernel stable branches. The fix involves upgrading the q_sum and q_psum variables from 32-bit to 64-bit integers to prevent integer overflow during quantum sum calculations.
Official patches are available from kernel.org:
- Kernel Commit 3912871344d6
- Kernel Commit 78b8d2f55a56
- Kernel Commit 7dbffffd5761
- Kernel Commit a6677e23b313
- Kernel Commit abe1d5cb7fe1
- Kernel Commit e35626f610f3
Workarounds
- Unload the sch_ets kernel module if ETS scheduling functionality is not required: modprobe -r sch_ets
- Blacklist the module to prevent automatic loading by adding blacklist sch_ets to /etc/modprobe.d/blacklist.conf
- Restrict access to netlink sockets and traffic control utilities to prevent unauthorized QoS configuration changes
- Implement network namespace isolation to limit the blast radius of potential exploitation attempts
# Temporary mitigation: Unload sch_ets module
rmmod sch_ets
# Permanent mitigation: Blacklist the module
echo "blacklist sch_ets" >> /etc/modprobe.d/blacklist.conf
# Verify module is not loaded
lsmod | grep sch_ets
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


