A small timing bug in the Mellanox (mlxsw) Spectrum ACL TCAM code can let background rehash work destroy a region still referenced by active filter entries, producing a classic kernel
use‑after‑free that leads to crashes and sustained denial of service — the flaw is tracked as CVE‑2024‑35854 and was fixed upstream by changing the rehash teardown logic so a failed migration no longer destroys a region that other threads may still reference.
Background / Overview
The mlxsw driver implements hardware-accelerated ACL (Access Control List) handling for Mellanox / NVIDIA Spectrum networking silicon. To keep on‑device TCAM structures efficient, the driver uses background “rehash” work that migrates filters (rules) between software regions and hardware chunks according to available credits and device state. That background work is asynchronous and may run concurrently with other kernel work that reads or modifies the same rule structures.
CVE‑2024‑35854 is a timing/race defect in exactly this rehash path: when migration finishes the rehash routine previously assumed that a
non‑negative credit value meant migration had completed successfully, and it proceeded to destroy the “migrated‑from” region. But a non‑negative credit value can also appear after a failed migration; destroying the region while other pieces of code still have pointers into it can therefore cause a use‑after‑free. The resulting memory access triggers Kernel Address Sanitizer (KASAN) reports and can lead to kernel oopses, panic, and loss of availability.
Multiple closely‑related fixes were landed in the same pull series to harden the rehash logic: not only the “don’t free on failed migration” change covered by CVE‑2024‑35854, but follow‑on fixes addressing memory leaks, warnings, and an activity‑update race in the same subcomponent were tracked as separate CVEs (the upstream work for Spectrum ACL TCAM produced a handful of tightly coupled fixes). Distributions incorporated these corrections in their kernel updates.
The technical problem, explained
How rehash and migration work
- The driver divides ACL rules into regions and chunks to organize TCAM allocations and migration.
- A delayed work item (the rehash worker) iterates regions and virtual chunks to migrate filter entries based on credits and device capacity.
- To avoid doing heavy lifting on the fast path, the driver uses markers (current chunk, current entry) to resume work when it yields and is re‑scheduled.
Where the race occurs
- Two independent delayed work contexts can touch the same structures: (1) the rehash worker that migrates filters, and (2) periodic activity update work that queries rule activity and inspects ventry->entry pointers.
- If rehashing fails partway through, the code previously used a non‑negative credit count to decide the migration had completed and proceeded to destroy the old region.
- If, at that moment, a concurrent worker still references an entry in the old region, that reference becomes a use‑after‑free when the region is destroyed. The kernel’s KASAN tooling surfaced this exact scenario in bug reports tied to this code path.
What the patch does (high level)
The upstream fix removes the incorrect assumption and prevents the code from destroying the region when migration has failed; the rehash teardown now checks the migration result and retains regions that could still be referenced. Other follow‑on changes added locking or cleanup to close related races and fix leaks that were exposed by the original correction. The end result is simpler and safer: do not free memory that may still be in use, and ensure rehash/resume markers are consistent across error paths.
Who and what is affected
- Primary exposure is to Linux systems that use the mlxsw kernel module for Mellanox / NVIDIA Spectrum devices — broadly: servers, appliances, and switches that run Linux and offload ACLs to Spectrum hardware.
- Impact is most visible where TCAM offload and heavy ACL churn are present (large rule sets, frequent updates, or scripted changes in cloud and data‑center environments).
- The vulnerability surfaces as kernel crashes and availability loss; depending on environment and how the device is used, the practical impact ranges from disrupted new connections to full service outages. Vendor and distribution advisories list the bug as a correctness/use‑after‑free class issue and distribute kernel fixes in their respective channels.
Important nuance: public vulnerability databases differ on attack vector and severity. The NVD lists a high base score (8.8) and a network attack vector in its vector string, while some vendor advisories (for example Amazon’s ALAS listing) present a lower, localized assessment for their packaging. This divergence reflects different risk models and packaging contexts; it does not mean the underlying bug is harmless — it means scoring and exposure can vary by distribution, kernel configuration, and system role. Administrators should treat the bug as operationally important for systems using Spectrum NICs and apply vendor patches promptly.
Practical impact and exploitation potential
- Primary impact: availability. A successful trigger produces KASAN splats and kernel oopses that can crash the host or kernel module, yielding sustained or persistent denial of service while the attacker continues triggers or in some cases even after due to corrupted state. This aligns with the MSRC description that characterizes availability loss as the primary consequence.
- Secondary impact: memory corruption class. Use‑after‑free bugs are also a common foothold for escalation or code‑execution chains when combined with other kernel bugs or misconfigurations. While no public, reliable PoC proving remote privilege escalation was published at the time of the upstream fix, the class of bug is inherently more dangerous than simple logic errors because it can corrupt kernel memory. Vendor advisories therefore treat the issue with appropriate gravity.
- Exploitability: Real‑world exploitation depends on multiple factors — kernel build flags, presence of KASAN (which is primarily a debugging tool), whether the device accepts attacker‑controlled flows or rule updates, and whether the attacker can cause the specific timing conditions. Given those dependencies, many distributions and cloud providers prioritized patching to remove the risk rather than waiting for a public exploit to appear.
Detection, indicators, and hunting guidance
If you operate Linux hosts with Spectrum adapters or switches running Linux, hunt for the following signs and telemetry:
- Kernel logs and dmesg entries mentioning KASAN or slab use‑after‑free lines that reference functions in the mlxsw ACL TCAM stack (for example: mlxsw_sp_acl_ctcam_region_entry_remove, mlxsw_sp_acl_tcam_vregion_rehash_work, mlxsw_sp_acl_tcam_vchunk_migrate_all). These exact call traces were observed in KASAN reports that motivated the patch.
- Repeated kernel oopses, unexplained reboots, or persistent unavailability that coincide with ACL churn or management operations (rule installs, massconfig pushes to devices).
- Missing or outdated kernel packages that are known to be vulnerable (see distribution advisory lists below). Inventory the running kernel with uname -r, check loaded modules with lsmod | grep mlxsw, and confirm package versions via your distro’s package manager.
Suggested quick checks (run as root or with equivalent privileges):
- Check kernel version: uname -r
- Check whether mlxsw is loaded: lsmod | grep mlxsw
- Inspect dmesg for KASAN/oom/oops signs: dmesg | egrep -i 'kasan|use-after-free|mlxsw_sp_acl|rehash'
- Confirm distro advisory status (use your vendor’s package manager or advisory feed) to know whether the running kernel includes the fix.
Mitigation and remediation (prioritized)
- Patch first. The only reliable mitigation is to install vendor/OS kernel updates that include the upstream fixes for the mlxsw spectrum_acl_tcam rehash issues. Major distributions published kernel updates that incorporate the corrections; Amazon Linux, Red Hat, SUSE, Oracle, Debian and others list patches in their advisories. Prioritize systems with Spectrum hardware or heavy ACL usage.
- If you cannot immediately patch, reduce exposure:
- Limit management plane access and control who can install or modify ACLs on vulnerable appliances.
- Restrict network paths that allow untrusted users to interact with devices that accept rule changes (e.g., configuration APIs, management interfaces).
- Consider temporary operational controls that reduce ACL churn (avoid mass automated rule pushes) until you can apply fixes. Note: there is no universal “safe” configuration that eliminates the kernel race apart from applying the fix; vendor advisories caution that no simple workaround is guaranteed.
- For highly exposed systems, consider kernel module unload or disabling offload features — but do this only after assessing operational impact. On many production systems, unloading mlxsw or disabling offload may be disruptive; treat these as last‑resort mitigations and test in a safe window. Vendor advisories emphasize patching over unloading.
- Monitor for evidence of exploitation and prepare incident response playbooks for service recovery. Because the bug can cause kernel panics, have boot and recovery procedures ready (serial console access, out‑of‑band management, ability to boot into known good kernels).
Distribution and vendor status (what was patched where)
Multiple Linux distribution advisories and vendor security pages documented the issue and the release of fixes:
- Amazon Linux ALAS entries list fixes for kernel-5.10 and kernel-5.4 ELTs and show the CVE mapping used by their packaging. Administrators who run Amazon Linux variants should consult the ALAS kernel advisories to confirm the package version for their instance class.
- SUSE and Red Hat integrated the upstream changes into their kernel updates; SUSE lists explicit kernel package minimums (for example a 6.4 branch package in their advisories) that include the fixes.
- Oracle and Debian references appear in public CVE trackers; Debian packaged the fix for linux‑libc‑dev and kernel series as part of their maintenance releases (Debian 6.1.90‑1 and similar backports were used). If you manage Debian hosts, check your Debian Security announcements and the kernel package version.
- Upstream kernel commits fixing the logic are in the stable/git trees; distribution advisory pages and package changelogs indicate the fixes were backported into the relevant stable branches. Administrators should prefer vendor kernel packages over attempting to manually cherry‑pick upstream commits unless you maintain a custom kernel workflow.
Note: vendor scoring differences — for example Amazon’s ALAS showing a lower CVSS versus NVD’s higher score — reflect context (packaging, exploitability assumptions, local vs network vector annotations). Do not let score variance alone decide priority; treat all systems that use Spectrum hardware as candidates for immediate patching.
Risk analysis: strengths of the fix and residual risks
Strengths
- The upstream changes are surgical and focused on preventing premature freeing of regions and cleaning up edge conditions in the rehash flow; that makes the fix straightforward to reason about and easier to backport into stable branches.
- Multiple vendors and distributions moved quickly to incorporate the correction into their kernels and issued advisories and packages, reducing the window of exposure for most managed environments.
Residual risks and caveats
- Use‑after‑free bugs are memory corruption bugs; while the fix closes the specific race, they remain the type of vulnerability that can be combined with other defects or misconfigurations for privilege escalation. Administrators should remain alert for related follow‑on patches and monitor for unusual kernel telemetry.
- The practical exploitability depends on environment specifics (kernel configuration, presence of KASAN, user privileges, network exposure). That makes it hard to produce a universal “exploitability” statement — remediation therefore must be prioritized based on asset value and criticality.
- Disparities in CVSS scoring and vendor advisories can create operational confusion; security teams should rely on a combination of vendor advisories, their own asset inventory (do you have Spectrum hardware?), and risk appetite to schedule patching.
Recommended action plan (for IT and security teams)
- Immediately identify all systems that load the mlxsw/ Spectrum drivers or that run on hardware known to use Mellanox Spectrum silicon:
- Inventory NICs and switches, check lsmod, lspci output, and device manifests.
- Patch systems in order of exposure and criticality:
- Edge and internet‑facing appliances, cloud instances with Spectrum NIC offload, and production switches first.
- Where patching cannot be done immediately:
- Limit access to management interfaces, pause bulk ACL pushes, and avoid configuration churn that might trigger rehash activity.
- Implement detection rules:
- Monitor kernel logs (dmesg, journald) for KASAN/mlxsw call traces and alert on repeated oopses.
- Post‑patch validation:
- Reboot into updated kernel, validate that kernel logs no longer show the KASAN signatures tied to mlxsw rehash, and run a controlled ACL churn test in staging to ensure stability.
- Document and communicate:
- Update change control, note which hosts were patched and when, and track affected inventory for compliance records.
Final assessment
CVE‑2024‑35854 is a classic kernel memory‑model bug in a highly specialized driver area that nevertheless has broad operational impact where Spectrum offload is in use. The patch is focused and effective — it corrects the faulty cleanup decision that caused the use‑after‑free — and distribution vendors acted to backport and publish fixes. Administrators who run Spectrum‑equipped systems should treat the issue as high priority for remediation: inventory your devices, apply the vendor kernel updates, and monitor kernel telemetry for KASAN or oops indicators until every vulnerable host is confirmed patched.
If you manage a fleet with Mellanox/NVIDIA hardware, schedule kernel updates into your maintenance windows now; the vulnerability’s primary effect — sustained or persistent denial of service — makes timely patching the most cost‑effective and reliable risk mitigation.
Source: MSRC
Security Update Guide - Microsoft Security Response Center