CVE-2024-56714

What it actually does

Double invocation of destroy_workqueue on the same private workqueue pointer in ionic driver error paths (AER reset) leads to invalid pointer handling and potential use-after-free.

Why it matters to the business

Unexpected kernel crashes or instability during hardware error recovery on affected network devices, increasing downtime risk in data-center and cloud environments with high device counts.

How an attack unfolds

An attacker with local or hardware-triggered error conditions (such as an AER event) forces ionic_reset_prepare and ionic_dev_teardown to run twice in succession; the second call passes an already-destroyed workqueue to destroy_workqueue, triggering the flaw.

How to fix it

Update to a kernel containing the fix that adds a guard against double destruction of the ionic workqueue; for listed qemu packages apply the stated fixed version 2.0.0+dfsg-2ubuntu1.30 or later.

How to confirm the fix worked

Confirm the patched kernel or qemu package is installed, then exercise AER reset paths while monitoring for workqueue destruction warnings or crashes.

Typical attack path

1. Trigger AER or firmware error path that invokes ionic_reset_prepare
2. Call ionic_dev_teardown which destroys the private workqueue
3. Re-invoke the same reset path a second time
4. Second destroy_workqueue receives stale pointer and crashes or corrupts state

How to detect it

Review kernel logs for repeated ionic reset or workqueue destruction messages around AER events; inspect for oops or panic traces referencing destroy_workqueue on ionic structures.

What your security team should do

• Apply the fixed kernel or qemu package immediately on systems exposing the ionic driver
• Prioritize hosts that have undergone recent AER or firmware error events
• Monitor vendor advisories for backports to older stable kernels