Cloudanix VulnDB

CVE-2026-89743

High · 7.7

CVSS

7.7

EPSS

0.1%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

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

  1. Obtain local access or the ability to control/impersonate an NSM device backend
  2. Trigger nsm_sendrecv_msg_locked() with a crafted oversized response length
  3. Read the disclosed kernel heap bytes returned to user space
  4. 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