CVE-2024-47730

What it actually does

Use-after-free in the HiSilicon QM crypto driver caused by injecting a QM error after stopping the queue, allowing the device to access memory that has already been released when the accelerator core reports a memory error.

Why it matters to the business

Local attackers on affected Linux systems using HiSilicon accelerators can trigger kernel crashes or escalate privileges, leading to denial of service or unauthorized code execution on servers and appliances.

How an attack unfolds

An attacker with local access induces a memory error condition on the accelerator; the driver then stops the queue before injecting the error, freeing memory that the still-active master OOO logic subsequently accesses, resulting in a use-after-free.

How to fix it

Upgrade the Linux kernel to a version containing commit 85e81103033324d7a271dafb584991da39554a89, which moves the error injection before the queue stop operation; apply distribution backports where available.

How to confirm the fix worked

Confirm the running kernel contains commit 85e81103033324d7a271dafb584991da39554a89, then reproduce memory-error conditions on the QM device and verify no use-after-free occurs and the master OOO is properly closed.

Typical attack path

1. Obtain local user access on a system with the vulnerable HiSilicon QM driver
2. Trigger or simulate an accelerator memory error report
3. Force queue stop before error injection completes
4. Leverage the resulting use-after-free for kernel memory corruption or code execution

How to detect it

Inspect kernel logs for oops/panic entries mentioning hisilicon qm, master ooo, or memory errors around queue stop operations; correlate with process activity on systems using the QM driver.

What your security team should do

• Prioritize kernel updates on all systems exposing HiSilicon QM accelerators
• Apply the fix within standard patch windows given low EPSS but high local impact
• Restrict unprivileged local access on unpatched hosts until remediation is complete