CVE-2026-99022 in Linux
Summary
by MITRE • 10/23/2026
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).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel regulator driver for the Linear Technology LTC3676 power management integrated circuit contained a critical implementation flaw regarding register access semantics, specifically concerning write-only command strobes. The vulnerability stems from the driver's generic regmap configuration which allowed read operations on registers that are strictly designed to be written to by hardware designers. In embedded systems and industrial control environments, precise adherence to datasheet specifications is paramount for system stability, yet this oversight in the kernel abstraction layer created a scenario where standard diagnostic tools could inadvertently trigger destructive hardware states.
The specific technical flaw involves two registers identified as HRST at address 0x1e and CLIRQ at address 0x1f. According to the LTC3676 datasheet specifications, these are write-only command strobes rather than status or data registers. Writing a value to HRST initiates a hard reset of the entire chip, effectively rebooting the connected system board. Similarly, writing to CLIRQ is intended solely to clear interrupt flags within the device's internal logic. The driver incorrectly mapped these addresses into the readable register space defined by regmap, allowing any process with appropriate permissions to execute read operations against them. This misconfiguration violates fundamental hardware interface principles where reading a write-only command strobe often triggers its associated action or returns undefined behavior that can be exploited for denial of service.
The operational impact of this vulnerability is severe and immediate, manifesting as an unintentional system reboot during routine debugging activities. When administrators or automated monitoring scripts utilize standard Linux kernel debug interfaces such as sysfs to dump the current state of hardware registers via paths like /sys/kernel/debug/regmap/2-003c/registers, the tool iterates through all accessible addresses in the defined range. Because HRST was included in this readable range, the read operation inadvertently executed the hard reset command. This results in a complete loss of service for any system relying on the LTC3676 regulator, disrupting critical operations and potentially causing data corruption if systems are not properly shut down before rebooting. In production environments or remote management scenarios, such an event could lead to significant downtime and operational disruption without any malicious intent from the user initiating the register dump.
To mitigate this vulnerability, the driver implementation was updated to strictly separate read and write capabilities for these specific registers. The regmap configuration callback was split into distinct sections ensuring that HRST and CLIRQ remain writable but are explicitly excluded from readable ranges. This change aligns the software behavior with the hardware datasheet specifications, preventing accidental execution of command strobes through read operations. By restricting access to only legitimate data registers such as those in the range LTC3676_BUCK1 through LTC3676_IRQSTAT, the system maintains stability while preserving necessary diagnostic capabilities for actual status and control registers. This fix exemplifies the importance of rigorous validation against hardware documentation when developing kernel drivers for embedded components.
From a security taxonomy perspective, this issue aligns with CWE-20 Improper Input Validation as it involves failing to restrict operations based on device-specific constraints, leading to unintended side effects. It also relates to CWE-479 Resource Release Without Proper Cleanup or Handling if the reset causes abrupt termination of processes without graceful shutdown procedures. In terms of attack vectors, while this is primarily a stability issue triggered by legitimate administrative tools, it could be leveraged in scenarios where an attacker with limited access privileges gains control over debug interfaces, thereby achieving a Denial of Service against critical infrastructure components. The ATT&CK framework would categorize the potential exploitation under T1499 Endpoint Denial of Service or potentially T1078 Valid Accounts if used to disrupt services via authorized but misused diagnostic tools. Ensuring that hardware-specific quirks are correctly handled in kernel drivers is essential for maintaining the integrity and availability of Linux-based embedded systems.