Look up another CVE · open CVE-2026-64366 in the interactive tracker
CVE-2026-64366
HID: wacom: fix slab-out-of-bounds write in wacom_wac_queue_insert
Published 2026-07-25 (3 months ago) by the Linux kernel CNA. Subsystem drivers/hid. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-64366 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.4-1 | Update the kernel and reboot. Fixed in 7.1.4-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.4-1 | Update the kernel and reboot. Fixed in 7.1.4-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
wacom_wac_queue_insert() calls kfifo_skip() in a loop when the kfifo doesn't have enough space for the incoming report. If the kfifo is empty, kfifo_skip() reads stale data left in the kmalloc'd buffer via __kfifo_peek_n() and interprets it as a record length, advancing fifo->out by that garbage value. This corrupts the internal kfifo state, causing kfifo_unused() to return a value much larger than the actual buffer size, which bypasses __kfifo_in_r()'s guard: if (len + recsize > kfifo_unused(fifo)) return 0; kfifo_copy_in() then performs an out-of-bounds memcpy, writing up to 3842 bytes past the 256-byte buffer. Add a !kfifo_is_empty() condition to the while loop so kfifo_skip() is never called on an empty fifo, and check the return value of kfifo_in() to reject reports that are too large for the fifo.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/hid/wacom_sys.c
- What this is
- HID WACOM DRIVERMAINTAINERS section matched on drivers/hid/wacom_* · linux-input@vger.kernel.org · Maintained
- Kernel module
- wacom
Check it on the machine
grep -wE 'CONFIG_HID|CONFIG_HID_SUPPORT|CONFIG_HID_WACOM' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w wacomPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookworm, trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_HID, CONFIG_HID_SUPPORT, CONFIG_HID_WACOM
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-25 (3 months ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.25%, higher than 15.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/hid
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.15 | 6.18.39 | ca899a926c11 |
| 6.15 | 7.1.4 | 57bdd10ad50d |
| 6.15 | 7.2 | 6b3014ec0e9a |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:AAttack vector, adjacent network
- The Wacom driver accepts Bluetooth HID devices, whose attacker-controlled descriptors and reports reach wacom_raw_event through HIDP or UHID. A malicious peripheral within Bluetooth range can therefore trigger the flaw.
- AC:LAttack complexity, low
- A single oversized crafted report can deterministically corrupt the empty FIFO state and trigger the overwrite. No race or condition outside the attacker's control is required.
- PR:NPrivileges required, none
- A connected malicious Bluetooth peripheral needs no account or kernel capability on the target. The report-processing path contains no privilege or authentication check.
- UI:NUser interaction, none
- Once the malicious peripheral is connected, it can transmit the triggering report without any concurrent victim action.
- S:UScope, unchanged
- The corruption occurs inside the host kernel and compromises resources governed by that same security authority; it does not inherently cross a VM or IOMMU boundary.
- C:HConfidentiality impact, high
- The large attacker-controlled heap overwrite can corrupt adjacent kernel objects and be developed into code-execution or arbitrary-memory-access primitives, exposing kernel and process memory.
- I:HIntegrity impact, high
- The report supplies thousands of attacker-controlled bytes beyond a small slab object, enabling corruption of adjacent objects and potential kernel control-flow hijacking.
- A:HAvailability impact, high
- The extensive slab overwrite can immediately cause a kernel oops or panic, and the triggering report can be sent repeatedly.