CVE-2021-46906

What it actually does

In hid_submit_ctrl, report size of zero causes hid_report_len to miscalculate transfer_buffer_length as 16384 bytes, resulting in an uninitialized kernel buffer being passed to the USB core and leaked to user space.

Why it matters to the business

Local users on affected Linux systems can read arbitrary kernel memory contents, which may contain credentials, keys, or other sensitive data and increases the risk of further privilege escalation on servers, desktops, or embedded devices running the kernel.

How an attack unfolds

An attacker with local access crafts a HID report descriptor that sets report->size to zero, triggers hid_submit_ctrl through a USB HID device or fuzzer, and reads the resulting 16384-byte uninitialized buffer returned by the USB subsystem to extract kernel memory contents.

How to fix it

Update the Linux kernel to a version containing the fix that modifies hid_report_len to use DIV_ROUND_UP and ensures hid_submit_ctrl calls the corrected helper; rebuild and reboot all affected systems.

How to confirm the fix worked

Confirm the running kernel version contains the upstream commit that updates hid_report_len and hid_submit_ctrl; attempt to reproduce the zero-size report condition in a test environment and verify that transfer_buffer_length is now calculated correctly and no oversized uninitialized buffer is submitted.

Typical attack path

1. Obtain local user access on a vulnerable Linux system
2. Create or attach a malicious USB HID device or use a syscall fuzzer to submit a zero-size report
3. Invoke hid_submit_ctrl so that transfer_buffer_length is computed as 16384
4. Read the leaked kernel memory from the URB completion buffer
5. Parse the returned data for useful artifacts such as pointers or credentials

How to detect it

Inspect kernel logs for KMSAN or UBSAN reports mentioning hid_submit_ctrl and large transfer lengths; look for unusual USB HID control transfers originating from untrusted local processes or device drivers; examine audit logs for processes that open /dev/hidraw or perform ioctl calls on HID devices immediately before anomalous memory access patterns.

What your security team should do

• Prioritize kernel updates on all internet-facing and multi-user systems within the next patching cycle
• Restrict unprivileged local USB device access via udev rules or kernel configuration where feasible
• Monitor for new kernel releases and test the fix in staging environments before broad deployment
• Review systems with high EPSS or downstream package dependencies first