Recently, a critical security vulnerability was discovered and patched in the Linux kernel, affecting the Mellanox Spectrum (mlxsw) network driver’s ACL (Access Control List) TCAM (Ternary Content Addressable Memory) subsystem. This vulnerability, tracked as CVE-2024-35855, was a race condition that could lead to a use-after-free (UAF) bug—one of the most dangerous classes of memory safety errors in the kernel. Below, we break down the issue in simple terms, show how it could be exploited, and explain how it was finally fixed.

Understanding the Issue: What Went Wrong?

The vulnerable path was found in the periodic rule activity update mechanism. The kernel schedules background work (delayed work) to check which ACL rules are active, traversing a list of rules and querying the hardware to get their current status. At the same time, there's another background work that can reorganize (rehash) these rules in memory to optimize performance (such as during massive rule changes).

Here’s the problem: If a rule entry on the list was reallocated by the rehash work (and possibly freed), but the activity update tried to access it at the same time, you end up with a classic use-after-free error in the kernel. This can crash the system, corrupt memory, or even be exploited for privilege escalation.

Exploitation: Why is This Bug so Bad?

In simple terms: An attacker with limited access could potentially use this bug to cause a kernel panic, crash the system, or execute arbitrary code if combined with other vulnerabilities. Since TCAM ACL rules can be influenced by privileged network configurations, this primarily affects environments using Mellanox Spectrum NICs with offloaded rules.

The key technical problem is the lack of appropriate locking (mutual exclusion) when accessing shared structures in parallel, letting two different "work queues" touch the same memory at the same time.

Proof of Concept

You need access to configure offloaded rules and trigger a situation where massive rule reordering (rehash) and activity querying occur at the same time. While a privileged user or malicious admin is the likely attacker, in multi-tenant environments, an exploit might be more feasible.

A simplified pseudocode showing the racing threads

// Thread 1 (activity update):
lock(vregion->lock); // <-- this was missing!
// iterates and reads ventry->entry
unlock(vregion->lock);

// Thread 2 (rehash):
lock(vregion->lock);
// reallocates and frees ventry->entry
unlock(vregion->lock);

Without the lock in thread 1, you have a race.
With the lock, both threads wait for each other and memory is accessed safely.

Crash Trace (from real report)

BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+x121/x140
Read of size 8 at addr ffff8881054ed808 by task kworker/:18/181

CPU:  PID: 181 Comm: kworker/:18 Not tainted 6.9.-rc2-custom-00781-gd5ab772d32f7 #2
...
Call Trace:
 mlxsw_sp_acl_tcam_flower_rule_activity_get
 mlxsw_sp_acl_rule_activity_update_work
...
Allocated by task 1039: ...
Freed by task 1039: ...

The Fix: Simple and Effective

The solution was to add proper locking around the code where the activity update reads rule entries. Both the update and rehash operations are now protected by the same mutex vregion->lock, so only one thread at a time can change or read those rule pointers.

Code Snippet (simplified)

// In the rule activity update function:
mutex_lock(&vregion->lock);
mlxsw_sp_acl_tcam_flower_rule_activity_get(...);
// safely access ventry->entry here
mutex_unlock(&vregion->lock);

This close-the-race approach ensures memory safety, even when two kernel work queues are running in parallel.

Affects recent Linux kernels (including 6.9.-rc2+).

- Particularly dangerous for high-performance servers and switches using Mellanox Spectrum network adapters with offloaded ACL.

References & Further Reading

- Kernel Commit Fixing the Bug (extern)
- Linux kernel Mailing List Discussion (extern)
- CVE Record on Mitre
- Linux kernel documentation: Delayed Work Queues
- KASAN (Kernel Address Sanitizer)

Conclusion

CVE-2024-35855 is a great example of how complex interactions within the Linux kernel can result in hard-to-find race conditions, especially in specialized subsystems like network offload engines. This bug could lead to serious outcomes if left unpatched. Always keep your systems—especially those running advanced networking hardware—updated with the latest security patches!

Timeline

Published on: 05/17/2024 15:15:22 UTC
Last modified on: 12/30/2024 18:11:57 UTC