CVE-2024-57986

What it actually does

The flaw stems from hid_apply_multiplier() assuming every Resolution Multiplier control resides inside a Logical Collection; when no such collection exists the multiplier_collection pointer is left uninitialized, allowing a NULL dereference or incorrect multiplier application during HID report parsing that results in memory corruption or kernel panic.

Why it matters to the business

Local authenticated users on affected Linux systems can trigger a denial-of-service crash, disrupting availability of any host that processes HID input from devices or emulated reports; the low EPSS and lack of KEV listing indicate limited observed in-the-wild exploitation but still requires prompt patching on Linux endpoints.

How an attack unfolds

An attacker with local access supplies a crafted HID report descriptor that omits a Logical Collection around a Resolution Multiplier control; during normal parsing the kernel reaches the unfixed code path, dereferences a NULL pointer, and crashes the system.

How to fix it

Upgrade the Linux kernel to a version containing the fix that explicitly sets multiplier_collection to NULL when no Logical Collection is found; apply vendor-supplied updates as they become available.

How to confirm the fix worked

Confirm the running kernel contains the commit that adds the NULL check for multiplier_collection; re-test with a fuzzer-generated report descriptor that omits Logical Collections around Resolution Multipliers and verify no crash occurs.

Typical attack path

1. Obtain local user access on a Linux host
2. Connect or emulate a HID device whose report descriptor lacks a Logical Collection for its Resolution Multiplier
3. Trigger report parsing via normal input subsystem activity
4. Cause NULL dereference leading to kernel panic

How to detect it

Review kernel logs for HID parsing errors or unexpected NULL pointer dereferences around hid_apply_multiplier; correlate with recent attachment of unknown HID devices; no public exploit artifacts are known.

What your security team should do

• Prioritize kernel updates on all Linux endpoints that process HID input
• Monitor for local privilege-escalation attempts that combine this DoS with other kernel bugs
• Restrict untrusted local accounts from attaching arbitrary HID devices until patched