CVE-2021-47081

What it actually does

Use-after-free in habanalabs Gaudi driver when hl_cs_allocate_job fails after hl_cb_kernel_create obtains a command buffer with elevated refcount; one reference is dropped via hl_cb_put and the buffer may be freed by a concurrent thread before cb->id is dereferenced.

Why it matters to the business

Kernel memory corruption on systems using Habanalabs Gaudi accelerators can lead to crashes, denial of service, or local privilege escalation; organizations running AI/ML workloads on affected hardware face unplanned downtime and potential data exposure until kernels are updated.

How an attack unfolds

An attacker with local access triggers the failure path in gaudi_memset_device_memory by forcing hl_cs_allocate_job to fail after the command buffer is created, races the reference-count drop, and reuses the freed object via its id field to corrupt kernel memory.

How to fix it

Apply a Linux kernel containing the upstream fix that saves cb->id before the hl_cb_put call; rebuild and reboot all affected systems or distributions that ship the habanalabs driver.

How to confirm the fix worked

Confirm the presence of the variable assignment for cb->id prior to hl_cb_put in gaudi_memset_device_memory; run kernel regression tests exercising command-buffer allocation failure paths; verify no UAF reports from KASAN or similar sanitizers under load.

Typical attack path

1. Obtain local code execution on a system with Habanalabs Gaudi hardware and load the driver
2. Craft input that causes hl_cs_allocate_job to fail inside gaudi_memset_device_memory
3. Trigger the release_cb branch so hl_cb_put drops a reference while another thread may free the buffer
4. Reuse the dangling cb->id pointer to read or write kernel memory
5. Escalate to kernel code execution or cause denial of service

How to detect it

Search kernel logs for oops or panic messages mentioning gaudi_memset_device_memory or habanalabs; inspect audit logs for unusual command-buffer allocation failures followed by crashes on Gaudi-equipped hosts.

What your security team should do

• Prioritize kernel updates on all systems exposing Habanalabs Gaudi accelerators
• Restrict local access to accelerator nodes until patches are deployed
• Monitor for kernel oops or KASAN reports referencing gaudi_memset_device_memory
• Include the driver in routine vulnerability scanning and patch-management cycles