CVE-2026-68218

What it actually does

Failure to call destroy_workqueue on an allocated workqueue in the dm1105 driver's remove callback leaves kernel memory allocated, producing a resource leak on device removal or module unload.

Why it matters to the business

Over long device lifetimes or frequent hot-plug cycles, memory consumption grows on affected Linux hosts, eventually causing performance degradation or out-of-memory conditions that disrupt media or DVB workloads.

How an attack unfolds

An attacker with local access repeatedly inserts and removes the dm1105 PCI device or loads and unloads the driver module; each cycle allocates a new workqueue that is never freed, steadily exhausting kernel memory until the system becomes unstable.

How to fix it

Apply the upstream kernel commit that adds the missing destroy_workqueue call in the dm1105 remove handler; rebuild and deploy the updated kernel image on affected systems.

How to confirm the fix worked

Review the dm1105 driver source to confirm destroy_workqueue is invoked before the remove function returns; exercise device removal under memory-leak detection tooling such as kmemleak and verify no new workqueue leaks are reported.

Typical attack path

1. Obtain local access or physical device access on a system using the dm1105 driver
2. Trigger repeated device removal or module unload cycles
3. Accumulate leaked workqueue memory until system impact is observed

How to detect it

Search kernel logs and dmesg for repeated workqueue allocation messages tied to dm1105; correlate with rising slab or workqueue memory counters via /proc/meminfo or bpftrace; examine crash dumps for workqueue objects that persist after device removal.

What your security team should do

• Prioritize kernel updates containing the dm1105 fix on any systems exposing the driver
• Add kernel memory usage and kmemleak alerts to existing host monitoring
• Limit unprivileged access to PCI hot-plug or driver load interfaces where feasible