Cloudanix VulnDB

CVE-2026-46001

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

May 27, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A coding error in the Linux kernel driver for certain hardware sensors can let a local user damage the system's core memory and take full control.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Local buffer overrun in pt5161l_read_block_data due to undersized 24-byte stack buffer receiving up to 32 bytes from i2c_smbus_read_block_data, plus incorrect positive return value after retry exhaustion that callers treat as success.

Why it matters to the business

Attackers with local access on affected Linux systems can corrupt kernel memory, potentially gaining full control of the host and disrupting hardware monitoring services.

How an attack unfolds

An attacker with local privileges supplies or emulates a pt5161l device that returns more than 24 bytes or inconsistent lengths on I2C block reads; the kernel driver overruns its stack buffer or processes stale data, leading to memory corruption that can be leveraged for privilege escalation.

How to fix it

Apply the upstream fix that resizes the buffer to I2C_SMBUS_BLOCK_MAX and returns -EIO on exhausted retries; rebuild and deploy the corrected kernel image to all affected systems.

How to confirm the fix worked

Confirm the driver source contains a 32-byte rbuf declaration and returns a negative error code when retries fail with a positive byte count; test by forcing oversized I2C responses and verifying no kernel oops or corruption occurs.

Typical attack path

  1. Obtain local user access on a system with the pt5161l hwmon driver loaded
  2. Trigger i2c_smbus_read_block_data calls via sensor reads or crafted device responses exceeding 24 bytes
  3. Exploit resulting stack overrun or mishandled positive return to corrupt kernel memory
  4. Escalate to ring-0 control or trigger denial of service

How to detect it

Review kernel logs for oops or stack traces mentioning pt5161l_read_block_data or i2c_smbus_read_block_data; inspect I2C bus traffic for block reads returning more than 24 bytes or repeated length mismatches.

What your security team should do

  • Prioritize kernel updates on any system exposing the pt5161l sensor
  • Restrict local user access and I2C device attachment where possible until patched
  • Monitor for kernel oops or stack-related panics involving pt5161l_read_block_data

The record

In the Linux kernel, the following vulnerability has been resolved: hwmon: (pt5161l) Fix bugs in pt5161l_read_block_data() Fix two bugs in pt5161l_read_block_data(): 1. Buffer overrun: The local buffer rbuf is declared as u8 rbuf[24], but i2c_smbus_read_block_data() can return up to I2C_SMBUS_BLOCK_MAX (32) bytes. The i2c-core copies the data into the caller's buffer before the return value can be checked, so the post-read length validation does not prevent a stack overrun if a device returns more than 24 bytes. Resize the buffer to I2C_SMBUS_BLOCK_MAX. 2. Unexpected positive return on length mismatch: When all three retries are exhausted because the device returns data with an unexpected length, i2c_smbus_read_block_data() returns a positive byte count. The function returns this directly, and callers treat any non-negative return as success, processing stale or incomplete buffer contents. Return -EIO when retries are exhausted with a positive return value, preserving the negative error code on I2C failure.

Affected packages

Ecosystem Package Introduced Fixed
openSUSE:Tumbleweed kernel-source 0 7.0.11-1.1

Related vulnerabilities