CVE-2026-43048

What it actually does

This is a Linux kernel memory-corruption vulnerability in the HID core event-processing path, specifically in hid_report_raw_event(). When a malformed or undersized HID input report is processed, the kernel attempted to zero-fill data past the valid incoming buffer area. That logic could lead to out-of-bounds memory access during subsequent processing. Because the vulnerable code runs in kernel context, successful exploitation can potentially cause kernel memory disclosure, kernel memory corruption, denial of service through a crash or panic, or, in the worst case, code execution with kernel privileges. The CVSS vector indicates adjacent attack requirements, meaning exploitation generally requires the attacker to present or influence a HID device or HID transport path such as USB, Bluetooth HID, or similar local/nearby device interfaces.

Why it matters to the business

A successful attack could let an untrusted or malicious peripheral destabilize or compromise Linux systems at the operating-system level. Operationally, this can result in workstation or server crashes, loss of availability, possible exposure of sensitive data in kernel memory, and potential full system compromise if the memory corruption is weaponized. The current EPSS score is low and stable, the issue is not listed in CISA KEV, and no public exploit maturity is indicated, which lowers immediate mass-exploitation risk; however, kernel-level HID flaws are still important for fleets that allow USB, Bluetooth, KVM, embedded HID, or other peripheral access.

How an attack unfolds

An attacker needs a path to deliver malformed HID reports to a vulnerable Linux kernel. In practical terms, that may involve connecting a malicious USB HID device, pairing or interacting with a malicious Bluetooth HID device, abusing a compromised peripheral, or reaching another HID transport exposed to the target system. The attacker crafts HID report data that is shorter than the report layout expected by the kernel. When the vulnerable kernel processes the event in hid_report_raw_event(), the flawed clearing behavior can trigger out-of-bounds memory access during later handling. Depending on memory layout, kernel configuration, hardening, and exploit reliability, this may produce a crash, information exposure, memory corruption, or a path toward kernel-level code execution. There is no indication from the provided intelligence that this CVE is currently exploited in the wild or used by ransomware campaigns.

How to fix it

Update affected Linux kernels to a version that includes the HID core fix that removes the unsafe memset() behavior and rejects undersized HID reports instead of continuing processing. Because no exact fixed versions were provided, use the security-advisory guidance from the relevant Linux distribution, kernel vendor, appliance vendor, or device manufacturer and deploy the first fixed kernel build they identify for CVE-2026-43048. Reboot systems after kernel updates so the fixed kernel is actually running. Where immediate patching is not possible, reduce exposure by restricting physical USB access, disabling unused Bluetooth HID functionality, blocking new/untrusted HID device pairing, enforcing USB device allow-listing where available, and applying endpoint controls that limit unknown HID-class devices. For high-risk systems, consider disabling unneeded HID modules or interfaces only after validating operational impact, because HID changes can affect keyboards, mice, KVMs, barcode scanners, touchscreens, and embedded controllers.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking the active kernel version after reboot and comparing it with the distribution or vendor advisory that includes the fix. Validate that vulnerable systems no longer run an unfixed kernel build. If source-based validation is possible, confirm the HID core patch is present in drivers/hid/hid-core.c and that undersized incoming HID report buffers are rejected rather than zero-filled past the incoming data. Review fleet inventory for Linux systems with USB, Bluetooth, or other HID interfaces enabled. For mitigation validation, test that unapproved USB HID devices are blocked, Bluetooth HID pairing is disabled or restricted where required, and endpoint/device-control policies are enforced.

Typical attack path

1. Identify a Linux system running a vulnerable kernel with HID support enabled.
2. Gain adjacent/local device interaction capability, such as physical USB access, Bluetooth HID proximity/pairing opportunity, or control of a connected HID-capable peripheral.
3. Present a malformed HID device or send malformed HID input reports that do not satisfy the report size expected by the kernel.
4. Trigger the vulnerable hid_report_raw_event() processing path.
5. Cause out-of-bounds kernel memory access, resulting in crash, memory disclosure, memory corruption, or potential privilege escalation depending on exploit reliability and system hardening.
6. Optionally use successful kernel compromise to disable security controls, access sensitive data, or establish persistence.

How to detect it

Look for signs of prior exploitation or attempted triggering in kernel and system logs rather than relying on network indicators, because this issue is typically exercised through local or adjacent HID device paths. Relevant sources include journalctl/kern.log/dmesg, audit logs for USB or Bluetooth device attachment, endpoint device-control logs, EDR telemetry for kernel crashes, crash dumps, kdump/vmcore artifacts, and Bluetooth pairing logs. Investigate kernel Oops, panic, KASAN, UBSAN, page fault, general protection fault, or slab out-of-bounds messages that include hid_report_raw_event(), hid-core, HID input processing, or unexpected report-size errors. Correlate those events with recent USB device insertion, Bluetooth HID pairing, new KVM or peripheral connection, unknown vendor/product IDs, or repeated attach/detach behavior. Since no public exploitation artifacts, actor-specific indicators, or ransomware usage were provided, detection should focus on anomalous HID device activity and kernel fault signatures rather than fixed malicious hashes, domains, or IP addresses.

• hid_report_raw_event
• drivers/hid/hid-core.c
• hid-core.c
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• BUG: KASAN
• kernel BUG
• Oops:
• general protection fault
• kernel panic
• Unable to handle kernel NULL pointer dereference
• HID:
• usbcore: registered new interface driver usbhid
• input: USB HID
• Bluetooth: HIDP
• hid-generic
• usbhid

What your security team should do

• Prioritize kernel updates on Linux workstations, kiosks, jump boxes, administrator endpoints, industrial/embedded Linux systems, and any systems exposed to untrusted physical peripherals or Bluetooth HID devices.
• Track vendor advisories for exact fixed kernel package versions and verify systems have rebooted into the fixed kernel after patch deployment.
• Temporarily restrict untrusted USB and Bluetooth HID device access on sensitive systems until patching is complete.
• Use device-control or USB allow-listing policies to limit keyboards, mice, KVMs, barcode scanners, and other HID devices to approved hardware where operationally feasible.
• Monitor kernel logs for HID-related crashes, KASAN reports, Oops events, and stack traces involving hid_report_raw_event or drivers/hid/hid-core.c.
• Treat unexplained kernel panics or HID subsystem faults shortly after new USB or Bluetooth device activity as potentially suspicious and preserve logs for forensic review.
• Because EPSS is low, KEV is false, and no exploit maturity is reported, prioritize based on exposure to untrusted peripherals rather than internet-facing risk.