CVE-2026-43380

What it actually does

This is a Linux kernel stack buffer overflow in the q54sj108a2 PMBus hardware monitoring driver debugfs read path. When a local user reads the affected debugfs interface, q54sj108a2_debugfs_read() can pass incorrectly sized and incorrectly ordered buffers to bin2hex(), causing a 32-byte device read to be expanded into 64 bytes and written into a 34-byte stack buffer. The overflow corrupts adjacent kernel stack memory and can result in kernel crash, denial of service, or potentially local privilege escalation to kernel-level execution depending on kernel build options, stack protections, and exploit reliability.

Why it matters to the business

An attacker who already has local access to a system with the affected kernel driver and exposed debugfs interface may be able to crash the host or escalate privileges to full system control. The most likely operational impact is instability or outage on Linux systems using the affected hardware monitoring driver, especially embedded, appliance, or server platforms that expose PMBus power-monitoring components. The vulnerability is not in CISA KEV, has low EPSS, and has no reported exploit maturity, so broad internet-scale exploitation is unlikely, but the high local impact warrants patching during normal kernel maintenance or faster for multi-user systems and appliances where local shell access is possible.

How an attack unfolds

An attacker first obtains a low-privileged local account or code execution on a Linux system running an affected kernel with the q54sj108a2 PMBus hardware monitoring driver in use. If debugfs is mounted and the relevant debugfs entry is readable, the attacker reads the vulnerable q54sj108a2 debugfs file. That read causes the kernel driver to call q54sj108a2_debugfs_read(), perform a PMBus/I2C block read, and then incorrectly convert the data using bin2hex() into an undersized stack buffer. The resulting overwrite corrupts kernel stack memory. In many environments this will produce an oops, panic, or watchdog-triggered reboot; with additional exploit engineering and favorable kernel conditions, the corruption may be shaped into kernel control-flow hijacking and local privilege escalation.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the upstream fix for the q54sj108a2_debugfs_read() buffer handling issue. Because no exact fixed package versions were provided, use the fixed kernel versions or security advisories from the relevant Linux distribution, appliance vendor, or kernel supplier. Where immediate patching is not possible, reduce exposure by unmounting debugfs where it is not required, restricting access to /sys/kernel/debug to trusted administrators only, disabling or unloading the q54sj108a2 driver if the hardware monitoring function is not needed, and limiting local shell access on affected systems. Kernel hardening features such as stack canaries, panic-on-oops policy review, lockdown mode, module restrictions, and least-privilege local access reduce exploitation reliability but do not replace patching.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor backport or upstream patch that expands the hex output buffer, corrects the bin2hex() argument order, and uses the actual read count in q54sj108a2_debugfs_read(). Do not rely only on uname output because many vendors backport fixes without changing the upstream kernel version. Check distribution security advisories, package changelogs, or source package diffs for the q54sj108a2 PMBus driver fix. Validate exposure by checking whether debugfs is mounted, whether q54sj108a2 or related PMBus modules are loaded, and whether q54sj108a2 debugfs entries exist under /sys/kernel/debug. In a controlled non-production environment, reading the relevant debugfs entry on a fixed kernel should not trigger a kernel oops, panic, KASAN report, or stack-protector warning.

Typical attack path

1. Gain local user-level access to a Linux system through legitimate credentials, a compromised service account, or another vulnerability.
2. Confirm the system is running an affected Linux kernel and that the q54sj108a2 PMBus hardware monitoring driver is loaded or reachable.
3. Confirm debugfs is mounted, commonly under /sys/kernel/debug, and that the q54sj108a2-related debugfs entry can be read.
4. Read the vulnerable debugfs file to trigger q54sj108a2_debugfs_read().
5. Cause bin2hex() to write beyond the end of the stack buffer during the debugfs read operation.
6. Achieve a kernel crash/denial of service, or attempt to turn the stack corruption into local privilege escalation if mitigations can be bypassed.

How to detect it

Look for evidence of local access to q54sj108a2 debugfs entries followed by kernel instability. Relevant sources include kernel logs from journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore data, auditd records for file reads under /sys/kernel/debug, EDR telemetry for processes accessing debugfs, and shell history where available. High-signal events include kernel oops or panic messages, stack-protector or KASAN reports, stack traces naming q54sj108a2_debugfs_read(), and audit records showing non-administrative users reading q54sj108a2-related debugfs files shortly before a crash or privilege anomaly. Because there is no known public exploit or unique network signature, absence of these indicators does not prove non-exploitation; focus on correlating local debugfs access, kernel fault logs, unexpected reboots, and subsequent suspicious root-level activity.

• q54sj108a2_debugfs_read
• q54sj108a2
• drivers/hwmon/pmbus/q54sj108a2.c
• /sys/kernel/debug
• /sys/kernel/debug/*q54sj108a2*
• BUG: stack guard page was hit
• stack-protector: Kernel stack is corrupted
• kernel BUG at drivers/hwmon/pmbus/q54sj108a2.c
• KASAN: stack-out-of-bounds
• general protection fault
• Oops:
• Kernel panic - not syncing

What your security team should do

• Prioritize patching affected Linux kernels on multi-user systems, appliances, build hosts, and systems where untrusted users or workloads can obtain local shell execution.
• Inventory systems for mounted debugfs and loaded q54sj108a2/PMBus hardware monitoring drivers to determine realistic exposure.
• Restrict or unmount debugfs on production systems unless it is explicitly required for operations or support workflows.
• Monitor kernel logs for oops, panic, stack-protector, KASAN, or stack trace events referencing q54sj108a2_debugfs_read or the q54sj108a2 driver.
• Review audit logs for unexpected reads under /sys/kernel/debug by non-administrative users, especially on systems with PMBus hardware monitoring enabled.
• If patching is delayed, consider disabling the affected driver or limiting access to systems where the hardware monitoring interface is present.
• Track Linux distribution and appliance vendor advisories because fixed versions may be delivered as backports rather than obvious upstream version changes.