In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_printer: take kref only for successful open printer_open()… (CVE-2026-64345)
Source GCVE Database
No CVSS score published yet
- Exploitation
Not in CISA KEV, no exploitation reported
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 1% of CVEs
What to do
AI-suggested
A fix has been implemented in the Linux kernel to address this issue by adjusting the reference counting logic in printer_open(). Users should apply the official kernel updates that include this fix once available.
Description
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_printer: take kref only for successful open printer_open() returns -EBUSY when the character device is already open, but it increments dev->kref regardless of the return value. VFS does not call ->release() for a failed open, so every rejected second open permanently leaks one reference. Move kref_get() into the successful-open branch.
Summary
The Linux kernel's usb gadget printer function (f_printer) had a flaw where printer_open() would increment the device's reference count (kref) regardless of whether the open succeeded or failed. Specifically, when printer_open() returned -EBUSY indicating the device was already open, it still incremented dev->kref. Since VFS does not call the release method on failed opens, this caused a permanent leak of one reference per rejected open attempt. The vulnerability was fixed by moving the kref_get() call into the branch that executes only on successful opens, preventing the reference leak.
Impact
The vulnerability causes a permanent reference count leak in the kernel when multiple open attempts are rejected. This can lead to resource exhaustion in the kernel over time, potentially degrading system stability or causing denial of service due to leaked references. There is no indication of code execution or privilege escalation from this issue.
References
- nvd.nist.gov/vuln/detail/CVE-2026-64345 (opens in a new tab)
- git.kernel.org/stable/c/30adce93d5c4a5a1ec29d9249e3fdfcc391d406b (opens in a new tab)
- git.kernel.org/stable/c/75c0ad13e136961328253742501b4efc3988a587 (opens in a new tab)
- git.kernel.org/stable/c/7f1f24c367938c5537e2308bf9a965f051d14774 (opens in a new tab)
- git.kernel.org/stable/c/8a5eba992c862b0c94411eecf9b7121e8636db38 (opens in a new tab)
- git.kernel.org/stable/c/94ec20d97aa51547965a539f660a1fe79c6929a3 (opens in a new tab)
- git.kernel.org/stable/c/bf20c94fa6aaff945f0ae3a23f3212cd299f28d9 (opens in a new tab)
Community reviews
Crowdsource mitigation strategies, share intel context, and vote on the most helpful responses.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.