CVE-2026-89629

What it actually does

The Linux kernel HID driver for Corsair Void devices parsed status and firmware events without validating their length. A malformed event can cause an out-of-bounds read in kernel context, which may disclose adjacent kernel memory or trigger a kernel oops/panic (availability impact). This is a local memory-safety defect in the HID input path, not a remote code-execution primitive.

Why it matters to the business

Unpatched Linux hosts that load the Corsair Void HID driver can become unstable or leak kernel memory if a malicious or faulty HID device sends undersized status or firmware events. The issue is not in CISA KEV, is not associated with ransomware, and has no known exploit maturity 38 days after publication, so urgency is driven by kernel hygiene rather than active campaigns. Exposure is limited to systems that bind hid-corsair-void (typically those with Corsair Void hardware or that accept matching USB HID devices); fleets without that hardware have little operational risk. Primary business consequences are headset-related kernel crashes and, in worse cases, limited information disclosure on multi-tenant or high-assurance Linux endpoints.

How an attack unfolds

An attacker who can attach or spoof a USB HID device that the kernel binds to the corsair-void driver—or who can influence reports from an already-attached Corsair Void device—delivers status or firmware events whose size does not match what the driver assumes. The unpatched driver reads past the supplied buffer, producing an out-of-bounds kernel read. Outcomes are typically a kernel warning/oops, a denial-of-service crash, or leakage of nearby kernel memory if the read result is observable. This is a physical/USB or compromised-peripheral path, not a network-facing attack. No named threat actors or campaigns are reported against this CVE.

How to fix it

Install a Linux kernel that includes the HID corsair-void fix which checks the size of status and firmware events before reading them and warns on unexpected values. Follow your distribution’s kernel security advisory for the package that contains this patch; no specific upstream or distro version numbers were supplied with this record. If Corsair Void devices are not required, unload or blacklist hid-corsair-void as a compensating control. Restrict untrusted USB HID devices with USB authorization, udev policies, or endpoint device-control so unapproved peripherals cannot bind this driver.

How to confirm the fix worked

Confirm the running kernel or distribution changelog includes the corsair-void status/firmware event size checks. Check whether hid-corsair-void is loaded (lsmod/modinfo) and whether Corsair Void hardware is present. After patching, verify legitimate devices still enumerate and that kernel logs remain clean during normal use; unexpected-size warnings after the fix indicate malformed input, not an unpatched driver. On hosts without the hardware, confirm the module is not loaded and that USB device-control policies would block an untrusted matching HID device.

Typical attack path

1. Obtain the ability to present a USB HID device that matches the Corsair Void driver (physical access, malicious peripheral, or compromised device firmware).
2. Cause the kernel to bind hid-corsair-void and process HID reports.
3. Send malformed status or firmware events with unexpected sizes.
4. Trigger an out-of-bounds read in the HID event parser.
5. Use the result as a kernel crash (denial of service) or, if readable, as a limited kernel-memory disclosure.

How to detect it

Pre-patch exploitation leaves few reliable artifacts because this is an out-of-bounds read with no public exploit. Hunt kernel logs (dmesg, journalctl -k, /var/log/kern.log, /var/log/messages), kdump/vmcore, and oops/panic traces around USB HID attach time for stacks or symbols referencing corsair-void or hid-corsair-void. Correlate with USB insertion events, new HID devices, and physical access. After the fix is applied, treat kernel warnings about unexpected status or firmware event sizes as evidence of malformed input worth investigating, not as proof of successful compromise. There are no associated APT or ransomware campaigns to hunt by actor name.

• corsair-void
• hid-corsair-void
• hid_corsair_void
• hid-corsair-void:
• USB HID attach followed by kernel Oops in corsair
• journalctl -k | grep -i corsair-void
• dmesg corsair-void unexpected

What your security team should do

• Patch Linux kernels on hosts that use Corsair Void headsets or that accept arbitrary USB HID devices, using your normal kernel update SLA rather than an emergency KEV-style break-glass window.
• Inventory systems with hid-corsair-void loaded and prioritize those that allow untrusted USB.
• Where the hardware is unused, blacklist or prevent autoload of hid-corsair-void.
• Enforce USB device allowlisting or authorization so unknown HID peripherals cannot bind vendor-specific drivers.
• Monitor kernel logs and crash dumps for corsair-void-related oopses and, after patching, for warnings about unexpected event sizes.
• Do not treat this as ransomware or mass-exploitation risk given KEV=false, no known actors, and exploit maturity none.