CVE-2024-35960

What it actually does

Improper linking of newly created flow rules into the fs tree in mlx5 results in rules with elevated refcount but NULL parent/root pointers; deletion via del_sw_hw_rule then dereferences the null parent causing a kernel crash.

Why it matters to the business

Systems using mlx5 networking hardware can experience sudden kernel panics during flow rule cleanup, leading to network downtime, service interruption, and potential data loss on affected Linux hosts.

How an attack unfolds

An attacker or misbehaving userspace program triggers create_flow_handle with conditions that cause duplicate pkt_reformat id handling; this results in a just-added rule being re-referenced without tree linkage, leaving a dangling rule that crashes the kernel when the flow group is later deleted.

How to fix it

Update the Linux kernel to the commit de0139719cdda82806a47580ca0df06fc85e0bd2 or later stable releases containing the fix that ensures add_rule_fg properly inserts parentless rules into the tree.

How to confirm the fix worked

Verify the running kernel contains commit de0139719cdda82806a47580ca0df06fc85e0bd2; test mlx5 flow rule creation and deletion paths under duplicate pkt_reformat scenarios to confirm absence of NULL parent crashes.

Typical attack path

1. Craft network flow configuration or packet reformat actions that produce duplicate pkt_reformat identifiers.
2. Invoke create_flow_handle which creates then double-references a rule without calling add_rule_fg properly.
3. Trigger deletion of the containing flow group, causing del_sw_hw_rule to dereference the NULL parent.
4. Kernel oops/panic occurs, disrupting the host.

How to detect it

Inspect kernel logs for oops traces mentioning mlx5, del_sw_hw_rule, fs rules, or NULL pointer dereference in flow group deletion; correlate with recent mlx5 flow steering or TC rule operations.

What your security team should do

• Prioritize kernel upgrade on all systems with mlx5 hardware to the fixed commit.
• Monitor for mlx5-related kernel oops in system logs until patches are deployed.
• Review any userspace tools that manage TC or eswitch flows for duplicate rule patterns.
• Apply the fix across the fleet within standard change windows given the high CVSS and in-the-wild trigger report.