Cloudanix VulnDB

CVE-2026-98860

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A mistake in handling errors from hardware input devices can make the system ignore problems and hand bad data to programs that read from those devices.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Negative error codes from transport drivers are implicitly promoted to size_t during comparison against size, causing hardware errors like -EPIPE to be treated as large positive values; this bypasses error paths, returns success, and supplies BPF programs with unmodified or stale buffers.

Why it matters to the business

HID input devices may silently fail under hardware errors, leading to unreliable operation of keyboards, mice, or other peripherals and potential exposure of uninitialized data to user-space programs.

How an attack unfolds

An attacker with local access induces a transport-level hardware error during an HID BPF hardware request; the erroneous return value is misinterpreted as success, allowing BPF programs to continue operating on stale or uninitialized data without detection.

How to fix it

Update the Linux kernel to a version containing the cast of size to ssize_t in the hid_bpf_hw_request error check; rebuild and deploy the patched kernel across affected systems.

How to confirm the fix worked

Inspect the kernel source for the corrected comparison that casts size to ssize_t before comparing against ret; confirm the change is present in the running kernel build and test error paths return the actual negative codes.

Typical attack path

  1. Obtain local access to a system running a vulnerable kernel with HID BPF enabled
  2. Trigger or simulate a hardware error in an HID transport driver
  3. Invoke a hid_bpf_hw_request that receives the negative error code
  4. Observe the comparison treating the error as success and subsequent use of the unmodified buffer

How to detect it

Search kernel logs and audit records for HID transport error returns coinciding with BPF hardware request activity; look for unexpected success paths after hardware faults in dmesg or BPF tracing logs.

What your security team should do

  • Apply the upstream kernel fix immediately given the recent publication date
  • Prioritize systems with active HID BPF usage or untrusted local users
  • Monitor kernel update channels for distribution packages containing the cast fix
  • Review and restrict unprivileged BPF program loading until patched

The record

In the Linux kernel, the following vulnerability has been resolved: HID: bpf: cast size to ssize_t when checking hid_bpf_hw_request As reported by Sashiko: If a transport driver encounters a hardware error and returns a negative error code such as -EPIPE, ret is implicitly promoted to size_t when compared against size. This causes the negative error code to evaluate as a large positive number, making the (ret > size) condition true. This silently converts the hardware error into a success return value and copies the unmodified buffer back, which could leave BPF programs operating on uninitialized or stale data. Fix this by casting size into ssize_t to return the actual negative error code.

Affected packages

Ecosystem Package Introduced Fixed