Live › vulnerability › CVE-2026-99022
Go to dashboardThe Linux kernel's ltc3676 regulator driver allowed reads of the write-only HRST and CLIRQ registers, and reading them fires the chip command. A plain debugfs register dump therefore hard-resets the board, causing a denial of service rather than code execution.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Only systems that run a Linux kernel with the ltc3676 regulator driver bound to a board, typically embedded hardware that uses this Analog Devices/Linear Technology power management chip. Servers and desktops without this chip are unlikely to have the driver active. Anyone who can read debugfs on such a board can trigger the reset, so restricting debugfs access also limits exposure.
No product ranges from the sources yet.
grep -i ltc3676 /boot/config-$(uname -r)ls /sys/kernel/debug/regmap/uname -rEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
regulator: ltc3676: don't read the write-only HRST and CLIRQ registers
HRST (0x1e) and CLIRQ (0x1f) are write-only command strobes. Writing HRST triggers a hard reset of the chip and writing CLIRQ clears the interrupt; reading them returns nothing useful, and the read itself fires the command.
The result is that a plain register dump resets the board:
cat /sys/kernel/debug/regmap/2-003c/registers
walks every readable register, hits HRST, and the board reboots.
Split the callback back in two so HRST and CLIRQ stay writable but are no longer readable. The readable range is left unchanged (LTC3676_BUCK1 ... LTC3676_IRQSTAT).
This page as .md · .json · in your agent: get_signal("CVE-2026-99022")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.