CVE-2026-43047

What it actually does

CVE-2026-43047 is a Linux kernel memory-corruption flaw in the HID multitouch handling path. When the kernel sends a HID feature-report request to a multitouch device, a malicious or faulty HID device can respond with a different report ID than the one requested. Without validating that the returned report ID matches the request, the HID core can process the response under the wrong report layout, potentially causing out-of-bounds writes in kernel memory. Successful exploitation can lead to local privilege escalation, kernel memory corruption, system crash, or potentially arbitrary code execution in kernel context. The attack requires local access sufficient to attach or interact with a malicious HID-class device, such as USB or another supported HID transport.

Why it matters to the business

Systems that allow local users or untrusted physical/peripheral access are most exposed, especially workstations, kiosks, shared Linux endpoints, lab systems, build machines, and servers where USB/HID attachment is possible. A successful attack could allow a lower-privileged local user or someone with physical access to gain full control of the affected system or cause outages through kernel crashes. The CVSS score is high, but current public exploitation signals are low: EPSS is 0.0012 with no 30-day increase, there is no known CISA KEV listing, no ransomware association, and no known mature public exploit reported in the supplied data. Operational urgency should be highest for endpoints or servers with exposed USB/HID access and lower for hardened systems where HID device attachment is blocked.

How an attack unfolds

An attacker first needs local or physical access to present a malicious HID multitouch device to the target system, or control over a device/emulation layer that the Linux kernel treats as a HID multitouch device. The attacker crafts the device behavior so that when the kernel requests a specific HID feature report, the device returns a response using a different report ID. Vulnerable kernels may then interpret the returned data using the wrong report definition. That mismatch can confuse HID core parsing and lead to an out-of-bounds write in kernel memory. Depending on kernel configuration, heap layout, hardening features, and reliability of the corruption primitive, the result may be a kernel crash or escalation from local access to kernel-level privileges.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the HID multitouch fix adding report-ID validation for feature-report responses. Because no exact fixed versions were supplied, use vendor advisories, distribution security trackers, or upstream stable kernel changelogs to identify the first fixed kernel for each supported branch. Prioritize updating systems where untrusted users can attach USB/Bluetooth/HID devices. Where immediate patching is not possible, reduce exposure by blocking untrusted HID devices, disabling unused USB ports in firmware or operating-system policy, enforcing USB device-control allowlists, disabling or restricting hidraw access, and limiting physical access to systems. Do not rely on detection alone, because exploitation may only produce generic kernel memory-corruption symptoms.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix for the HID multitouch report-ID validation issue, not merely that an updated package is installed but not rebooted into. Check the active kernel with commands such as `uname -a` and compare it against the distribution advisory or fixed package metadata. For source-based or custom kernels, confirm the HID multitouch code rejects feature-report responses when the returned report ID differs from the requested report ID. Validate exposure reduction by confirming USB/HID device-control policies are active and that untrusted HID devices cannot be attached or accessed by non-administrative users. If possible, perform testing in a controlled lab with a benign HID test device or emulator to confirm mismatched report IDs are rejected without kernel warnings, crashes, or raw-event processing.

Typical attack path

1. Obtain local physical access, peripheral access, or another path to present a HID multitouch device to the Linux system.
2. Connect or emulate a malicious HID multitouch device that advertises reports capable of triggering the vulnerable code path.
3. Wait for or cause the kernel HID multitouch driver to issue a feature-report request.
4. Return a crafted response whose report ID does not match the report ID requested by the kernel.
5. Cause the vulnerable HID core path to parse the response using the wrong report structure, leading to out-of-bounds kernel memory writes.
6. Use the resulting memory corruption to crash the system or, if exploitation is reliable, escalate privileges to kernel level.

How to detect it

Look for evidence of suspicious or unexpected HID multitouch device activity followed by kernel memory-corruption symptoms. Relevant log sources include `dmesg`, system journal logs, kernel logs such as `/var/log/kern.log` or `/var/log/messages`, crash dump infrastructure such as kdump/vmcore, endpoint USB device-control logs, EDR device telemetry, and audit logs for access to `/dev/hidraw*`. Investigate timelines where a new HID, USB HID, Bluetooth HID, or multitouch device is enumerated shortly before a kernel oops, panic, KASAN report, slab corruption message, or unexplained reboot. Because this vulnerability does not define a unique network signature and exploitation occurs through local HID interaction, detection is largely behavioral and forensic. Focus on systems with unexpected HID multitouch devices, repeated connect/disconnect activity, kernel crashes involving `hid-multitouch`, `usbhid`, `hidraw`, or HID report parsing, and any abnormal privilege escalation or new root-level process activity after the crash or device event.

• hid-multitouch
• HID: multitouch
• usbhid
• hidraw
• /dev/hidraw
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: KASAN
• kernel BUG
• Oops:
• general protection fault
• Kernel panic
• slab-out-of-bounds
• out-of-bounds write
• USB HID
• New USB device found
• input: * as /devices/*/input/input*

What your security team should do

• Inventory Linux systems that permit physical, USB, Bluetooth HID, or other untrusted peripheral access, and prioritize them for kernel updates.
• Patch affected Linux kernels through vendor-supported packages and reboot systems into the fixed kernel.
• For high-risk endpoints, kiosks, shared workstations, and sensitive servers, enforce USB/HID allowlisting or block unapproved HID devices until patching is complete.
• Restrict access to hidraw and related device nodes to trusted users and services only.
• Review endpoint and kernel logs for recent crashes, KASAN reports, HID parsing errors, or unexpected new HID multitouch devices, especially on systems with physical access exposure.
• Treat unexplained kernel crashes following HID device connection as potentially suspicious and preserve logs, crash dumps, and device metadata for forensic review.
• Monitor distribution security advisories for exact fixed kernel versions if fixed-version data is not yet available in internal tooling.