CVE-2021-47056

What it actually does

Improper initialization ordering sets ADF_STATUS_PF_RUNNING before adf_dev_init succeeds, allowing adf_vf2pf_shutdown to call adf_iov_putmsg and perform mutex_lock on an uninitialized or destroyed vf2pf_lock, resulting in KASAN-detected user-memory-access.

Why it matters to the business

Systems using Intel QAT virtual functions may suffer kernel crashes or instability during device probe failures or shutdown, causing denial of service and potential data loss on affected Linux hosts.

How an attack unfolds

An attacker with local access triggers adf_dev_init failure paths while the status flag remains set, causing subsequent shutdown code to dereference an invalid lock and panic the kernel.

How to fix it

Apply the upstream kernel fix that moves the ADF_STATUS_PF_RUNNING assignment to occur only after adf_dev_init returns success; rebuild and deploy the patched kernel on affected hosts.

How to confirm the fix worked

Confirm the corrected conditional flag assignment appears after the adf_dev_init return-value check in the QAT driver source; test VF attach/detach cycles for absence of KASAN reports.

Typical attack path

1. Cause adf_dev_init to return non-zero (e.g., via resource contention or malformed VF configuration)
2. Invoke adf_dev_shutdown which checks ADF_STATUS_PF_RUNNING
3. Execute adf_vf2pf_shutdown leading to mutex_lock on uninitialized vf2pf_lock

How to detect it

Search kernel logs and crash dumps for KASAN user-memory-access reports referencing __mutex_lock, adf_iov_putmsg, adf_vf2pf_shutdown, or the qat_dh895xccvf module during probe or shutdown sequences.

• BUG: KASAN: user-memory-access in __mutex_lock.isra.0
• adf_iov_putmsg+0x118
• adf_vf2pf_shutdown+0x4d
• qat_dh895xccvf

What your security team should do

• Prioritize kernel updates containing the QAT ordering fix on any system exposing Intel QAT VFs
• Disable QAT VF drivers where the hardware is not required
• Include QAT-related KASAN signatures in kernel crash monitoring