CVE-2026-31741

Vulnerability

Analysis

The vulnerability resides in the rz-mtu3-cnt counter driver within the Linux kernel. The core issue is a lack of state checking when a user writes to the sysfs enable file. Each write to this file unconditionally increments or decrements the runtime PM usage count, regardless of whether the counter is already enabled or disabled. This leads to an imbalance in the usage count if the same value is written multiple times. On a write of 0 to disable an already disabled counter, the runtime PM usage count underflows, which triggers a kernel warning message: "Runtime PM usage count underflow!". Additionally, the disabled code path attempts to disable the channel again, accessing hardware registers while the clocks are off, which can cause undefined behavior or system instability. Conversely, writing 1 multiple times increments the usage count each time, requiring an equal number of 0 writes to restore it, effectively allowing a denial-of-service condition where the counter cannot be properly powered down [Description].

Attack

Vector and Preconditions

The vulnerability is triggered through local access to the sysfs interface for the rz-mtu3-cnt device. An attacker must have write permissions to the sysfs enable attribute, which typically requires root privileges or access to the device's sysfs entry. The attack is simple: repeatedly writing the same enable value (0 or 1) to the file causes the described count imbalance. No special hardware or network position is needed; it is a purely software-triggered issue through standard user-space interaction [Description].

Impact

The impact of this vulnerability is primarily a denial-of-service condition. The runtime PM framework may become locked in an inconsistent state, causing unwanted side effects. Hardware registers may be accessed without clocks, potentially leading to system hangs or unexpected behavior. Additionally, if a write of 0 occurs while a PWM is in progress, the PWM is stopped without the counter properly releasing the underlying MTU3 channel, which could leave hardware in an inconsistent state [Description].

Mitigation

The fix, as referenced in the kernel stable git commits [1][2][3][4], adds a check against a cached count_is_enabled value. If the user attempts to set the enable file to the same value as the current state, the driver now exits early without modifying the runtime PM usage count or performing hardware operations. This prevents the usage count imbalance and ensures that hardware is only performed when the state actually changes. Users should apply the patched kernel version containing the commit that corrects this behavior [Description].