CVE-2023-54015

What it actually does

Incorrect freeing of a priv structure allocated by a different thread in mlx5_devcom_register_device leads to use-after-free when devcom allocation fails.

Why it matters to the business

Linux systems using mlx5 network hardware may experience kernel crashes, memory corruption, or potential local privilege escalation, disrupting server operations and requiring urgent patching across fleets.

How an attack unfolds

An attacker with local access triggers concurrent device registration and failure paths in the mlx5 driver to cause the erroneous free and subsequent use of the dangling pointer.

How to fix it

Update to a kernel containing commit 3dfc1004d9afbf689087ae1eafd88f55481984c7 or later; for eck-operator-fips update to 3.0.0-r2 or newer.

How to confirm the fix worked

Verify the running kernel includes the referenced commit or equivalent backport; inspect source for the conditional priv free logic; test device registration error paths under concurrency.

Typical attack path

1. Obtain local code execution on a system with mlx5 hardware
2. Trigger concurrent calls to mlx5_devcom_register_device from multiple threads
3. Force devcom allocation failure in one thread
4. Trigger use of the freed priv structure from the other thread
5. Achieve memory corruption or crash

How to detect it

Review kernel logs for mlx5 and use-after-free warnings; correlate with device registration events; examine crash dumps for mlx5_devcom symbols.

What your security team should do

• Prioritize kernel updates on all systems exposing mlx5 devices
• Monitor for kernel oops or panic logs related to mlx5_devcom
• Apply updates before the CISA-style deadlines if this enters KEV
• Restrict local unprivileged access on high-value systems until patched