CVE-2026-68358

What it actually does

Use-after-free in the nzxt-kraken3 hwmon driver caused by a race between hid_input_report and hid_device_io_start when the probe path fails after IO has been started; the missing hid_device_io_stop before hid_hw_stop leaves pending input reports referencing freed structures.

Why it matters to the business

Local attackers on systems with NZXT Kraken AIO coolers can trigger kernel memory corruption, leading to crashes, denial of service, or potential privilege escalation; low EPSS and no KEV listing indicate limited real-world exploitation so far, but any affected Linux distribution still requires patching.

How an attack unfolds

An attacker with local access attaches or resets the USB device during driver probe, forces a failure after hid_device_io_start, and wins the race so that a later hid_input_report dereferences already-freed memory; no named threat actors or ransomware campaigns are associated with this flaw.

How to fix it

Apply the upstream fix that inserts hid_device_io_stop before hid_hw_stop in the error path; rebuild or update to a kernel containing the resolution for the nzxt-kraken3 driver; until a patched kernel is available, unloading the module or physically disconnecting the device reduces exposure.

How to confirm the fix worked

Confirm the presence of the hid_device_io_stop call immediately before hid_hw_stop in the probe error path of nzxt-kraken3.c; verify the running kernel version contains the commit that resolved the race; test probe-failure paths with the affected hardware to ensure no UAF warnings appear in the kernel log.

Typical attack path

1. Obtain local user access on a Linux system with the nzxt-kraken3 driver loaded
2. Trigger or time a device probe that reaches hid_device_io_start
3. Cause the probe to fail after IO start but before full initialization
4. Win the race with a concurrent hid_input_report to trigger the UAF
5. Leverage the resulting memory corruption for denial of service or escalation

How to detect it

Review kernel logs for use-after-free warnings or KASAN reports referencing hid_input_report or nzxt_kraken3 during device probe; correlate USB device attach events with subsequent oops or panic entries; no public exploit artifacts are known, so focus on generic UAF kernel crash signatures.

What your security team should do

• Prioritize kernel updates for any distribution shipping the nzxt-kraken3 driver
• Monitor EPSS trend (currently declining) and re-evaluate if new exploit code appears
• Restrict local access on systems that expose USB HID devices to untrusted users
• Add the driver to the organization's vulnerable-driver allow/deny list until patched