CVE-2024-50302

What it actually does

This is a Linux kernel HID core information-disclosure flaw caused by an allocated HID report buffer not being zero-initialized before use. A local attacker with low privileges can trigger specially crafted HID report handling paths so that stale kernel memory contents may be copied into a report buffer and exposed outside the intended kernel boundary. The direct impact is confidentiality loss of kernel memory; it does not by itself provide code execution, privilege escalation, data modification, or denial of service, but leaked kernel pointers or sensitive memory fragments can help bypass exploit mitigations such as KASLR when chained with another local kernel vulnerability.

Why it matters to the business

Systems running an affected kernel or downstream package may expose sensitive kernel memory to a local attacker or already-compromised user process. Because this vulnerability is listed in CISA KEV with active exploitation and a remediation due date of 2025-03-25, it should be treated as operationally urgent even though the standalone severity is moderate and EPSS is low. The most important business risk is exploit chaining: attackers can use memory disclosure to make other Linux kernel attacks more reliable, potentially leading to broader host compromise, credential theft, lateral movement, or service disruption.

How an attack unfolds

An attacker first obtains local code execution or access to an account on a vulnerable Linux system. They then interact with the HID subsystem through an available HID interface, such as a physical HID device, a virtual HID path, or a user-accessible hidraw/uhid interface depending on system configuration. By submitting or provoking specially crafted HID reports, the attacker reaches a code path where the kernel allocates a report buffer that was not cleared. Because the buffer may contain residual kernel memory, the attacker reads the resulting report data and extracts leaked bytes. In real intrusions, this type of bug is most useful as part of a multi-stage local exploit chain: the leak can disclose kernel addresses or memory layout details that make a separate privilege-escalation vulnerability more dependable. The KEV listing indicates exploitation has been observed in the wild; provided threat context points to broader zero-day and Linux kernel privilege-escalation campaigns rather than a single uniquely attributable actor for this flaw.

How to fix it

Apply the vendor kernel update that includes the HID core fix to zero-initialize report buffers at allocation time, then reboot into the fixed kernel. For the supplied affected package data, Ubuntu 14.04 LTS flashplugin-nonfree is listed as fixed in version 11.2.202.554ubuntu0.14.04.1; however, the vulnerability description is in the Linux kernel HID subsystem, so organizations should also validate the installed kernel package against their Linux distribution’s security advisory and ensure the running kernel contains the upstream fix. If immediate patching is not possible, reduce exposure by restricting access to /dev/hidraw* and /dev/uhid, removing unnecessary HID device passthrough into containers or virtual machines, limiting local shell access, enforcing least privilege for device groups, disabling unneeded USB/Bluetooth HID functionality where operationally feasible, and using endpoint controls to block untrusted local exploit tooling. Mitigations should be considered temporary because they do not correct the underlying kernel memory disclosure.

How to confirm the fix worked

Confirm remediation by verifying both the installed package version and the kernel currently running after reboot. On Linux systems, compare `uname -r` and distribution package metadata, such as `dpkg -l 'linux-image*'`, `rpm -q kernel`, or the equivalent package manager output, against the vendor advisory containing the HID core zero-initialization fix. For the supplied Ubuntu 14.04 package data, verify flashplugin-nonfree is at least 11.2.202.554ubuntu0.14.04.1 if that package is in scope. Also confirm there are no stale vulnerable kernels selected as the default boot target and that hosts have actually rebooted after patch installation. Exposure checks should include reviewing permissions on /dev/hidraw* and /dev/uhid, identifying systems with HID device passthrough, and confirming unprivileged users cannot access HID interfaces unless required. Where available, vulnerability scanners should check the distribution-specific fixed kernel build rather than relying only on the upstream CVE identifier.

Typical attack path

1. Gain local execution on a Linux host through phishing, stolen credentials, exposed service compromise, malware, or another initial-access method.
2. Identify that the host is running an affected Linux kernel or downstream package with vulnerable HID core behavior.
3. Check for accessible HID attack surfaces such as /dev/hidraw*, /dev/uhid, connected USB/Bluetooth HID devices, containers or sandboxes with device passthrough, or permissive device ACLs.
4. Send crafted HID report requests or data that exercise the vulnerable report-buffer allocation and handling path.
5. Read returned HID report data and harvest leaked kernel memory bytes, such as pointer values or stale data fragments.
6. Use the memory disclosure to improve reliability of another local kernel exploit or to support follow-on host compromise.
7. Clean up temporary tooling and continue post-exploitation activity if the leak enabled a successful exploit chain.

How to detect it

Detecting prior exploitation is difficult because successful exploitation may only read leaked kernel memory and may not crash the system or create a durable artifact. Focus on indirect evidence: audit logs for unusual access to HID device nodes, endpoint telemetry showing unknown binaries opening /dev/hidraw* or /dev/uhid, kernel logs around unexpected HID device creation or removal, USB/Bluetooth HID attachment events, and suspicious local exploit tooling executed shortly before privilege changes. On systems with auditd, review SYSCALL and PATH events involving /dev/hidraw*, /dev/uhid, /sys/class/hidraw, and /sys/bus/hid. In EDR telemetry, look for nonstandard processes repeatedly opening HID device paths, probing sysfs HID metadata, or running from temporary directories while interacting with device files. In kernel logs, investigate unusual HID parsing errors, repeated HID report activity, newly connected HID devices at odd times, KASAN/KMSAN warnings, kernel oops messages, or crashes near HID handling. Because this issue is most valuable as part of an exploit chain, correlate HID anomalies with signs of Linux privilege escalation: creation of unexpected root shells, new setuid files, kernel module loading, credential dumping, tampering with security tools, or sudden UID 0 process execution by previously low-privileged users.

• /dev/hidraw
• /dev/hidraw0
• /dev/hidraw1
• /dev/uhid
• /sys/class/hidraw
• /sys/bus/hid
• hidraw
• uhid
• hid-generic
• HID:
• usbcore: registered new interface driver usbhid
• usbhid
• Bluetooth HID
• KASAN:
• KMSAN:
• BUG: KASAN
• kernel BUG
• kernel oops
• general protection fault
• segfault
• audit:
• type=PATH
• type=SYSCALL

What your security team should do

• Prioritize remediation on Linux workstations, servers with local multi-user access, virtualization hosts, container hosts with device passthrough, kiosk systems, and systems that permit USB or Bluetooth HID devices.
• Treat the issue as time-sensitive because it is in CISA KEV, has active in-the-wild exploitation, and had a KEV remediation deadline of 2025-03-25, even though standalone CVSS and EPSS are not high.
• Patch and reboot affected Linux systems; verify the running kernel, not just the installed package inventory.
• Audit and restrict access to HID device nodes, especially /dev/hidraw* and /dev/uhid, and remove users from device-access groups unless there is a business requirement.
• Review containers, virtual machines, and sandboxed workloads for unnecessary HID, USB, or device passthrough permissions.
• Hunt for signs of local kernel exploit staging on systems with suspicious HID access, especially when paired with other Linux kernel privilege-escalation attempts.
• Correlate this exposure with other known local kernel vulnerabilities because memory disclosure is commonly used to make privilege-escalation chains more reliable.
• Increase monitoring for unauthorized USB/Bluetooth HID device attachment on sensitive endpoints and administrative workstations.
• If patching legacy systems is not feasible, isolate them, reduce local user access, disable unneeded peripheral interfaces, and plan accelerated retirement or migration.