Cloudanix VulnDB

CVE-2026-93061

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A small mistake in Linux kernel debug code for one graphics component could let a local user peek at a tiny bit of nearby memory that should stay hidden, though it is hard to trigger and only happens when looking at special debug files.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Theoretical
Impact
Data Exposure
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Misuse of vsnprintf return value (intended length) instead of actual bytes written leads to host1x_debug_output and host1x_debug_cont passing an over-long count to the output callback, enabling a limited stack over-read when formatted debug strings exceed 256 bytes on debugfs sinks.

Why it matters to the business

Kernel debug paths may leak adjacent stack memory or trigger faults during inspection of host1x GPU state; exposure is narrow, low-probability, and confined to debugfs, producing negligible operational disruption for most deployments.

How an attack unfolds

An attacker with local access crafts input that triggers a host1x debugfs read producing a >256-byte formatted string; the oversized length is supplied to the emit function, causing an out-of-bounds read of the stack buffer before the corrected vscnprintf path was applied.

How to fix it

Upgrade the Linux kernel to a release containing the vscnprintf correction in the host1x debug helpers; rebuild and reboot with the patched kernel. Where immediate patching is impossible, restrict debugfs access via mount options or SELinux policy.

How to confirm the fix worked

Inspect the host1x debug source for replacement of vsnprintf with vscnprintf in host1x_debug_output and host1x_debug_cont; confirm the running kernel version includes the fix and that debugfs entries no longer exhibit the over-read behavior under crafted long-format input.

Typical attack path

  1. Obtain local unprivileged shell on affected Linux system
  2. Locate and open host1x debugfs entries that invoke the debug helpers
  3. Trigger formatting of a string exceeding 256 bytes
  4. Observe or crash on the resulting stack over-read

How to detect it

Examine kernel logs and debugfs access records for repeated or anomalous host1x debug reads; correlate with any stack traces or oops reports mentioning host1x_debug_output; no widespread exploitation artifacts are expected given the narrow trigger conditions.

What your security team should do

  • Apply the upstream host1x debug fix at the next scheduled kernel update window
  • Audit systems for unnecessary debugfs exposure and tighten permissions
  • Monitor EPSS and exploit maturity; no urgency indicated by current low scores or KEV listing

The record

In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Avoid stack over-read in debug output helpers host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit. This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur. Fix by switching to vscnprintf(), which returns the number of bytes actually written.

Affected packages

Ecosystem Package Introduced Fixed