CVE-2024-45007

What it actually does

The vulnerability permits destroy_workqueue() to be invoked from within a work item executing on the workqueue being destroyed, triggered via kref decrement, violating kernel workqueue invariants and risking use-after-free or deadlock conditions in the xillybus driver.

Why it matters to the business

Systems relying on the xillybus character driver may experience kernel instability, crashes, or degraded I/O performance, increasing downtime risk for affected Linux deployments; low exploit probability reduces immediate urgency despite widespread kernel prevalence.

How an attack unfolds

An attacker with local access or the ability to interact with xillybus devices triggers a kref decrement that schedules a work item on its own per-device workqueue; when that item runs it calls destroy_workqueue on the queue it is executing from, leading to undefined kernel behavior. No named threat actors have been observed exploiting this specific flaw.

How to fix it

Upgrade the Linux kernel to a version containing commit 409b495f8e3300d5fba08bc817fa8825dae48cc9 or later stable releases that introduce a module-global workqueue for the affected work item while retaining per-device queues for other operations.

How to confirm the fix worked

Verify the presence of commit 409b495f8e3300d5fba08bc817fa8825dae48cc9 in the running kernel source or confirm the xillybus module no longer calls destroy_workqueue from its own work items via code review or runtime tracing.

Typical attack path

1. Obtain local code execution or device access on a Linux system using the xillybus driver
2. Perform operations that cause a kref decrement on the relevant xillybus object
3. Force the resulting work item to execute and invoke destroy_workqueue on its own queue
4. Trigger resulting kernel panic, hang, or memory corruption

How to detect it

Review kernel logs for xillybus workqueue destruction attempts or oops traces referencing destroy_workqueue; examine audit logs for unusual device interactions preceding crashes; no public exploitation artifacts are known.

What your security team should do

• Apply the referenced kernel commit or distribution update immediately on systems exposing xillybus devices
• Audit for xillybus usage across the fleet and prioritize servers and embedded devices
• Monitor kernel logs for workqueue-related warnings or oops until patches are deployed