CVE-2024-46784

What it actually does

Improper error handling in mana_create_txq/rxq causes napi_disable() to be invoked before NAPI initialization and hrtimer setup, triggering kernel panic via hrtimer_cancel in the cleanup path.

Why it matters to the business

Results in denial-of-service crashes on Linux systems using the MANA network driver; low urgency given absence from KEV, stable low EPSS, and 754 days since publication with no ransomware use.

How an attack unfolds

Attackers or automated processes trigger error paths during mana_alloc_queues or rxq/txq creation (e.g., via network configuration or driver load), forcing premature NAPI cleanup that panics the kernel; referenced threat actors include espionage and financially motivated groups exploiting similar Linux kernel resource issues.

How to fix it

Upgrade the Linux kernel to commit 386617efacab10bf5bb40bde403467c57cc00470; update github.com/openshift/source-to-image to version 1.1.10-0.20180427153919-f5cbcbc5cc6f where applicable.

How to confirm the fix worked

Confirm presence of fix commit 386617efacab10bf5bb40bde403467c57cc00470 in kernel source; reproduce mana_create_rxq error paths in test environments and verify no panic occurs.

Typical attack path

1. Initiate mana queue allocation or reconfiguration
2. Induce error condition in rxq/txq setup before NAPI enablement
3. Execute mana_destroy_rxq cleanup path
4. Invoke napi_disable on uninitialized state leading to hrtimer panic

How to detect it

Search kernel logs and panic reports for stack traces containing napi_disable, hrtimer_cancel, mana_destroy_rxq, and page_fault_oops in the context of mana driver initialization.

What your security team should do

• Prioritize kernel updates on systems using MANA driver
• Review boot and network logs for related panic signatures
• Test driver initialization under failure conditions post-update