Linux kernel developers have shipped a fix for a use-after-free vulnerability in the IMM parallel-port SCSI driver that could allow a local attacker to crash the system or, in a worst-case scenario, escalate privileges. The flaw, tracked as CVE-2025-68324, was addressed by adding a single line of code that synchronously cancels a delayed work item before the driver’s memory is freed during device removal.

A Classic Race Condition in a Forgotten Driver

The bug lives in the scsi: imm driver, which supports certain legacy parallel-port SCSI host adapters. When the driver receives a SCSI command, it schedules a delayed work item (imm_tq) to handle the operation asynchronously. The trouble starts when the device is detached: the cleanup routine (imm_detach) frees the driver’s private data structure (imm_struct), but it didn’t wait for any pending or in-flight work to complete. That left a window where the work callback (imm_interrupt) could still access the now-freed memory—a classic use-after-free.

The kernel’s workqueue API offers several cancellation functions. The driver originally relied on cancel_delayed_work, which removes a work item from the queue but does not block if the callback is already running. The fix, accepted into the scsi-staging tree for kernel 6.19, swaps in disable_delayed_work_sync. This call blocks until any running instance of the work item finishes and prevents it from being re-queued, guaranteeing that no code will touch the freed structure afterward.

“The patch author explicitly documented the race and wrote a minimal change that calls the synchronous cancellation API in the detach path,” kernel mailing list discussions noted. “It’s a focused, low-risk kernel patch: one insertion to make teardown synchronous, with a clearly stated ‘Fixes:’ line referencing an older commit and a standard Signed-off-by chain.”

How Serious Is This for You?

For most Windows users: There is no direct impact. This is a Linux kernel vulnerability, and the IMM driver is not part of Windows. However, if you dual-boot into a Linux distribution on the same machine, run Linux virtual machines under Hyper-V, or use Windows Subsystem for Linux (WSL) with a custom kernel that includes this driver, you may need to take action on those Linux instances. Standard WSL2 kernels from Microsoft typically omit parallel-port SCSI support, so the risk is minimal there.

For IT professionals managing Linux servers: Any system that loads the imm module—whether for actual parallel-port SCSI hardware or through a legacy kernel configuration—is potentially vulnerable. Attackers with local access could trigger the race condition by repeatedly attaching and detaching a device, or by crafting SCSI requests that cause the work item to be scheduled while a detach is in progress. The most likely outcome is a kernel panic and system crash, causing a denial of service. Privilege escalation is theoretically possible but would require a high degree of skill and favorable memory layout.

For kernel developers and contributors: This CVE is a textbook example of why asynchronous work items must be properly synchronized with object lifetime. The pattern of “schedule delayed work → free object” has caused dozens of similar bugs across the kernel. The fix—always cancel synchronously before freeing—is a best practice that should be applied during driver code review.

How We Got Here

The IMM driver has been part of the Linux kernel for decades, originally written to support Iomega Zip drives and other parallel-port SCSI devices. Over time, the driver was updated to use kernel workqueues, but the teardown path was never updated to account for the asynchronous nature of delayed work. The vulnerability likely existed since the conversion, but it remained unnoticed because parallel-port SCSI hardware is rare today.

This isn’t an isolated incident. “Over the last several years, kernel review and static analysis have repeatedly found similar issues across networking, storage, and platform drivers,” maintainers pointed out. “The fix pattern applied here—use of the synchronous cancellation APIs—is a stabilizing best practice and is being applied across multiple subsystems when such races are discovered.”

What to Do Now

  1. Check if you’re affected: Run lsmod | grep imm on your Linux systems. If the module is loaded, or if modinfo imm shows it available, you are potentially vulnerable. Also check dmesg for references to IMM or parallel-port SCSI detection.

  2. Update your kernel: The fix is part of the scsi-staging tree for kernel 6.19 and is being backported to relevant stable trees. Monitor your distribution’s security tracker for CVE-2025-68324. Ubuntu, Debian, and other major distributions have already recorded the CVE and will ship patched kernels in their next updates. Apply the update as soon as it’s available.

  3. Mitigate until you can patch: If you cannot immediately reboot into a fixed kernel, unload and blacklist the imm module:
    - Unload it: sudo modprobe -r imm
    - Prevent automatic loading: Create /etc/modprobe.d/blacklist-imm.conf with the line blacklist imm.
    - Avoid any physical detachment or reconfiguration of parallel-port SCSI devices until the kernel is updated.

  4. For custom kernel builders: The patch is trivial to backport. Apply the change that adds disable_delayed_work_sync in the imm_detach function, rebuild, and test.

After patching, verify by checking the kernel changelog or using uname -r to confirm you are running a version that includes the fix. Run stress tests with KASAN enabled if you need to reproduce the issue in a controlled environment.

What’s Next?

This patch won’t be the last of its kind. Kernel maintainers are increasingly using automated tools to detect use-after-free patterns, and the workqueue subsystem is under scrutiny. “The presence of one UAF due to delayed work suggests other drivers might have analogous issues; a comprehensive audit of delayed-work usage across in-tree drivers remains necessary,” security researchers noted.

For Windows administrators, the broader lesson is clear: asynchronous code and resource cleanup are a dangerous mix, regardless of the operating system. Whether you’re writing a Windows driver, a kernel module, or a user-space service, ensuring that background work is fully stopped before freeing resources is a fundamental security practice.