CVE-2026-43380

Updated on 08 May 2026

Severity

7.1 High severity

Details

CVSS score
7.1
CVSS vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H

Overview

About vulnerability

In the Linux kernel, the following vulnerability has been resolved:

hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read

The q54sj108a2_debugfs_read function suffers from a stack buffer overflow due to incorrect arguments passed to bin2hex(). The function currently passes ‘data’ as the destination and ‘data_char’ as the source.

Because bin2hex() converts each input byte into two hex characters, a 32-byte block read results in 64 bytes of output. Since ‘data’ is only 34 bytes (I2C_SMBUS_BLOCK_MAX + 2), this writes 30 bytes past the end of the buffer onto the stack.

Additionally, the arguments were swapped: it was reading from the zero-initialized ‘data_char’ and writing to ‘data’, resulting in all-zero output regardless of the actual I2C read.

Fix this by:

  1. Expanding ‘data_char’ to 66 bytes to safely hold the hex output.
  2. Correcting the bin2hex() argument order and using the actual read count.
  3. Using a pointer to select the correct output buffer for the final simple_read_from_buffer call.

Details

Affected product:
AlmaLinux 9.2 ESU , TuxCare 9.6 ESU
Affected packages:
kernel @ 5.14.0 (+1 more)

In the Linux kernel, the following vulnerability has been resolved:

hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read

The q54sj108a2_debugfs_read function suffers from a stack buffer overflow due to incorrect arguments passed to bin2hex(). The function currently passes ‘data’ as the destination and ‘data_char’ as the source.

Because bin2hex() converts each input byte into two hex characters, a 32-byte block read results in 64 bytes of output. Since ‘data’ is only 34 bytes (I2C_SMBUS_BLOCK_MAX + 2), this writes 30 bytes past the end of the buffer onto the stack.

Additionally, the arguments were swapped: it was reading from the zero-initialized ‘data_char’ and writing to ‘data’, resulting in all-zero output regardless of the actual I2C read.

Fix this by:

  1. Expanding ‘data_char’ to 66 bytes to safely hold the hex output.
  2. Correcting the bin2hex() argument order and using the actual read count.
  3. Using a pointer to select the correct output buffer for the final simple_read_from_buffer call.

Fixes