CVE-2026-53011

What it actually does

This is a Linux kernel use-after-free flaw in the taprio traffic-control scheduler under net/sched. During a schedule switch, the old operational schedule is queued for RCU freeing, but the code can continue using a pointer to an entry from that old schedule and assign it as the current entry. If the race is reached, the kernel may dereference freed memory. Practical outcomes can include kernel memory corruption, denial of service through a crash or panic, and, depending on exploitability on a specific kernel build and hardening configuration, possible local privilege escalation. Exploitation is expected to require the ability to configure taprio qdiscs, typically CAP_NET_ADMIN or equivalent network-administration privileges, including in some container or namespace configurations where that capability is exposed.

Why it matters to the business

The primary operational risk is loss of availability on Linux systems using or permitting taprio traffic-control scheduling, especially systems handling time-sensitive networking, industrial networking, telecom, edge, or latency-sensitive workloads. A successful attack could crash affected hosts or potentially allow a locally privileged attacker to gain greater control of the system. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported public exploit maturity, and has a low EPSS score, so urgency is lower than for actively exploited internet-facing vulnerabilities; however, kernel flaws should still be prioritized on systems where untrusted users, containers, or automation can manipulate traffic-control settings.

How an attack unfolds

An attacker first needs local access or a foothold that provides network administration capability on a Linux system. The attacker configures a taprio qdisc with an administrative schedule and causes a transition from the admin schedule to the operational schedule. When advance_sched() evaluates the schedule change, switch_schedules() promotes the new schedule while the old schedule is queued for RCU freeing. Vulnerable kernels can then continue using a stale pointer into the old schedule and assign or modify it after it has been freed. With simple triggering, this may produce a kernel fault or panic. A more advanced attacker would attempt to shape heap state around the freed schedule entry so the stale pointer references attacker-influenced memory, potentially turning the memory corruption into privilege escalation. No public exploitation or named threat actor activity is currently indicated by the supplied intelligence.

How to fix it

Upgrade to a kernel version that includes the upstream fix for the taprio advance_sched() schedule-switch use-after-free. Where vendor fixed package versions are available, apply the relevant distribution kernel security update rather than relying only on upstream version numbers. Reboot into the patched kernel after installation, because kernel package updates do not protect the running kernel until it is replaced. If immediate patching is not possible, reduce exposure by removing CAP_NET_ADMIN from untrusted users and containers, disabling or avoiding taprio qdisc use where not required, restricting access to traffic-control tooling and netlink configuration paths, and limiting who can create or administer network namespaces. Mitigations should be treated as temporary because the vulnerable code remains present until the kernel is updated.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, contains the fix by checking the active kernel version after reboot and comparing it with the distribution advisory or fixed kernel package. Validate that systems no longer boot into older vulnerable kernels. On representative hosts, verify whether taprio is in use with traffic-control inspection commands such as listing qdiscs and looking for taprio configurations. Confirm untrusted workloads do not retain CAP_NET_ADMIN unless explicitly required. For hardened environments, run regression tests for time-sensitive networking or taprio-based scheduling after patching to ensure traffic shaping behavior remains correct.

Typical attack path

1. Obtain local execution on a Linux host or inside a container/network namespace with CAP_NET_ADMIN or equivalent permissions.
2. Verify that the kernel supports the taprio traffic-control scheduler and that traffic-control configuration is permitted.
3. Use tc or equivalent netlink operations to create or modify a taprio qdisc with an administrative schedule.
4. Trigger a schedule switch so the old operational schedule is queued for RCU freeing while advance_sched() still references an entry from it.
5. Race or repeatedly trigger the vulnerable path until the stale pointer is dereferenced or reassigned.
6. Cause a kernel crash/denial of service, or, in a more sophisticated exploit, attempt to manipulate freed kernel memory for privilege escalation.

How to detect it

To assess prior exploitation, review kernel logs, audit logs, container runtime logs, and command telemetry for unusual taprio qdisc activity followed by kernel faults or reboots. Useful sources include journalctl/kern.log/dmesg, auditd execve records, eBPF or EDR process telemetry, sudo logs, shell history where available, and container orchestration audit events showing capabilities such as CAP_NET_ADMIN. Look for repeated invocations of tc qdisc commands using taprio, netlink traffic-control configuration from unexpected processes, creation of privileged containers or network namespaces, and kernel crash signatures around sch_taprio, advance_sched(), RCU, or KASAN use-after-free reports. Absence of these artifacts does not prove the vulnerability was not triggered, because successful kernel exploitation may leave limited logs, especially if the host panicked or logs were not persisted.

• BUG: KASAN: use-after-free
• use-after-free in advance_sched
• advance_sched
• sch_taprio
• taprio
• tc qdisc add
• tc qdisc replace
• tc qdisc change
• qdisc taprio
• net/sched
• general protection fault
• kernel BUG
• Unable to handle kernel paging request
• RCU
• CAP_NET_ADMIN

What your security team should do

• Inventory Linux systems where taprio qdiscs are enabled or where users, containers, or services have CAP_NET_ADMIN.
• Prioritize patching hosts that combine local multi-user access, container workloads, exposed network namespaces, or time-sensitive networking configurations.
• Apply the vendor kernel update that contains the taprio use-after-free fix and reboot into the patched kernel.
• Remove CAP_NET_ADMIN from untrusted containers and service accounts wherever possible.
• Audit use of tc/netlink-based traffic-control configuration and restrict it to trusted administrative workflows.
• Monitor kernel logs for crashes, KASAN use-after-free reports, or suspicious taprio/qdisc reconfiguration events.
• Because the issue is not KEV-listed, has low EPSS, and has no known exploit maturity, track it through normal kernel patch cycles unless taprio or delegated network administration is broadly used.