CVE-2026-89743
High · 7.7CVSS
7.7
EPSS
0.1%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A problem in how the Linux kernel reads responses from certain hardware devices can let someone with local access see pieces of internal memory they are not supposed to.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Low
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Information Disclosure
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Out-of-bounds read in nsm_sendrecv_msg_locked() where an unbounded device-reported virtqueue length is stored in msg->resp.len and then copied by parse_resp_raw() past the end of the response buffer into user space, exposing adjacent kernel heap contents.
Why it matters to the business
Attackers with local access can obtain sensitive kernel memory that may contain credentials, keys, or other data structures, increasing the risk of privilege escalation or further compromise on affected Linux systems.
How an attack unfolds
An attacker supplies or emulates a malicious NSM backend that reports a virtqueue used-ring length larger than the posted response buffer; the kernel stores this length without clamping and parse_resp_raw() copies the excess bytes to user space, disclosing heap data.
How to fix it
Update the Linux kernel to a version containing the fix that clamps the stored response length to the size of the response buffer before calling parse_resp_raw().
How to confirm the fix worked
Inspect the source of nsm_sendrecv_msg_locked() and parse_resp_raw() for the added length clamp; verify that well-behaved devices continue to function and that oversized lengths are now truncated.
Typical attack path
- Obtain local access or the ability to control/impersonate an NSM device backend
- Trigger nsm_sendrecv_msg_locked() with a crafted oversized response length
- Read the disclosed kernel heap bytes returned to user space
- Use the leaked data to locate kernel structures or bypass protections for further exploitation
How to detect it
Examine kernel logs and audit records for unusual NSM device interactions or virtqueue length reports; correlate with processes invoking nsm ioctls or userspace reads that return unexpectedly large data.
What your security team should do
- Prioritize kernel updates on systems exposing the NSM misc driver
- Review device virtualization or backend configurations that could supply untrusted NSM responses
- Monitor for local privilege-escalation attempts following any heap disclosure
The record
In the Linux kernel, the following vulnerability has been resolved: misc: nsm: bound the device-reported response length nsm_sendrecv_msg_locked() stores the virtqueue used-ring length reported by the NSM device into msg->resp.len without bounding it to the response buffer. A malicious or buggy backend can report a length larger than the response buffer; parse_resp_raw() then copies that many bytes out of the fixed buffer to user space, disclosing adjacent kernel heap (an out-of-bounds read). The request path already floors its length in fill_req_raw(); the response path lacks the symmetric check. Clamp the stored length to the size of the response buffer. Well-behaved devices report no more than the posted buffer size, so conforming traffic is unaffected.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|