Cloudanix VulnDB

CVE-2026-90416

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's network hardware debugging code could let a local user read a little more memory than intended or cause a crash.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Buffer Overflow
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Stack out-of-bounds read in RDMA/mlx5 debugfs cc_params handler: get_param formats u32 congestion value with signed %d into 11-byte buffer; values with bit 31 set produce 12-byte decimal strings, causing snprintf to report 12 bytes while only storing 11, so simple_read_from_buffer copies one byte past the buffer.

Why it matters to the business

Local information disclosure or kernel crash on systems exposing mlx5 RDMA debugfs entries; low remote exploitability but can disrupt RDMA workloads or leak limited stack data when debugfs is accessed.

How an attack unfolds

An attacker with local access writes a congestion parameter value >= 0x80000000 via the corresponding debugfs file or triggers the read path; the kernel then performs the oversized read, potentially leaking one stack byte or causing a page fault.

How to fix it

Apply the upstream fix that enlarges the buffer to hold the largest unsigned decimal representation, switches the format specifier to %u, and uses scnprintf to report only bytes actually written; update to a kernel containing the resolution for CVE-2026-90416.

How to confirm the fix worked

Confirm the corrected buffer size, %u formatting, and scnprintf usage in the mlx5 cc_params debugfs code; test by writing 0x80000000 and verifying the read returns exactly the correct decimal string without oops or extra bytes.

Typical attack path

  1. Obtain local shell or process with access to /sys/kernel/debug/mlx5/.../cc_params
  2. Trigger get_param() read of a u32 value with high bit set
  3. Observe kernel oops, panic, or read of adjacent stack byte via simple_read_from_buffer

How to detect it

Review kernel logs for stack-out-of-bounds warnings or oops mentioning mlx5, cc_params, or simple_read_from_buffer; inspect debugfs access attempts on RDMA devices.

What your security team should do

  • Prioritize kernel updates on systems using mlx5 RDMA hardware
  • Restrict debugfs access via mount options or permissions where RDMA is not required
  • Monitor kernel logs for oops involving mlx5 debugfs or simple_read_from_buffer

The record

In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs get_param() reads a congestion parameter as a u32 but formats it with the signed "%d" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as "-2147483648\n" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with "%u" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored.

Affected packages

Ecosystem Package Introduced Fixed