CVE-2024-36974

What it actually does

Missing validation of TCA_TAPRIO_ATTR_PRIOMAP on the second invocation of taprio_change() allows userspace to supply arbitrary mqprio attributes after the first call has set dev->num_tc to a non-zero value, resulting in the kernel operating on attacker-controlled data structures.

Why it matters to the business

Local attackers on affected Linux systems can achieve kernel-level code execution or privilege escalation, potentially compromising the entire host and any workloads it runs; the issue affects widely deployed kernel versions and requires prompt patching to limit exposure.

How an attack unfolds

An attacker with local access first invokes the taprio qdisc with a valid priomap to trigger num_tc initialization, then calls taprio_change() again supplying a malicious TCA_TAPRIO_ATTR_PRIOMAP; because validation is skipped, arbitrary data reaches kernel memory, enabling out-of-bounds writes or control-flow hijacking. Reported exploitation attempts have been linked to espionage and financially motivated campaigns targeting Linux kernel flaws.

How to fix it

Upgrade the Linux kernel to a version containing commit c6041e7124464ce7e896ee3f912897ce88a0c4ec or later; rebuild and reboot with the patched kernel. Where immediate updates are impossible, restrict unprivileged local access and avoid exposing taprio qdisc configuration to untrusted users.

How to confirm the fix worked

Confirm the running kernel contains commit c6041e7124464ce7e896ee3f912897ce88a0c4ec (or the equivalent stable backport) via uname -r and git log on the kernel tree; recompile any out-of-tree modules against the fixed tree and verify that taprio_parse_mqprio_opt now validates the priomap on every call.

Typical attack path

1. Obtain local user access on a vulnerable Linux host
2. Load or configure a taprio qdisc with a valid priomap to set num_tc
3. Re-invoke taprio_change with a crafted TCA_TAPRIO_ATTR_PRIOMAP attribute
4. Trigger kernel code paths that consume the unvalidated data to corrupt memory or execute attacker-controlled code
5. Escalate to root or kernel privileges and install persistence or exfiltrate data

How to detect it

Review kernel audit logs and dmesg for repeated taprio configuration attempts or oops/panic entries following qdisc changes; inspect system call traces for multiple tc qdisc add/change operations on the same device within a short window; correlate with process execution of tools that invoke netlink rtnetlink messages targeting TCA_TAPRIO_ATTR_PRIOMAP.

What your security team should do

• Prioritize kernel upgrades on all internet-facing and multi-tenant systems within the next patching cycle
• Audit systems for use of taprio qdisc and limit its configuration to trusted processes only
• Monitor EPSS and threat-intel feeds for any increase in public exploits targeting this class of scheduler validation issues
• Apply kernel live-patching where available and test the fix in staging before broad deployment