CVE-2024-36021

What it actually does

Race condition in hns3 PF initialization allows devlink reload to access uninitialized hardware registers, resulting in kernel crash.

Why it matters to the business

Systems using affected hns3 hardware can experience unexpected kernel panics and service interruption when devlink operations occur during driver initialization.

How an attack unfolds

An attacker with local access triggers a devlink reload command during the narrow window of PF hardware initialization in the hns3 driver, causing the kernel to dereference uninitialized resources and crash.

How to fix it

Update the Linux kernel to a version containing commit 50b69054f455dcdb34bd6b22764c7579b270eef3 or later stable release that holds devl_lock during hns3 PF initialization.

How to confirm the fix worked

Confirm the running kernel contains commit 50b69054f455dcdb34bd6b22764c7579b270eef3; test by attempting devlink reload during module load and verify no crash occurs.

Typical attack path

1. Obtain local access on a system with hns3 hardware
2. Time a devlink reload operation to coincide with PF initialization
3. Trigger kernel crash via uninitialized register access

How to detect it

Review kernel logs for oops/panic entries referencing hns3 and devlink during initialization; correlate with devlink reload audit events around module load times.

What your security team should do

• Prioritize kernel upgrade on all systems exposing hns3 interfaces
• Monitor for kernel oops or panic logs containing hns3 and devlink references
• Restrict unprivileged devlink access until patched