CVE-2026-89721 in Linux
Summary
by MITRE • 09/11/2026
In the Linux kernel, the following vulnerability has been resolved:
phy: rockchip-samsung-dcphy: fix out-of-range max_register
The PHY register block is 64KB, so with a register stride of 4 the last accessible register sits at offset 0xfffc. max_register names 0x10000, one register past the end of the mapping: dumping the registers through the regmap debugfs interface reads beyond the ioremapped region and oopses on the unmapped page. The oops fires with the regmap lock held, so later PHY operations deadlock.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified in the Linux kernel's rockchip-samsung-dcphy driver stems from an incorrect configuration of register mapping boundaries within the physical layer subsystem. Specifically, the max_register field was set to a value that exceeds the actual memory-mapped I/O region allocated for the PHY hardware registers. The underlying hardware specification defines a register block size of 64 kilobytes with a stride of four bytes per register. This configuration dictates that the highest valid register offset is located at hexadecimal address 0xfffc, which represents the final accessible word within the mapped memory space. However, the driver incorrectly configured max_register to point to 0x10000, effectively addressing one full register slot beyond the end of the ioremapped region. This discrepancy creates a boundary violation where software attempts to access physical addresses that are not backed by valid kernel mappings or hardware responses.
The operational impact of this misconfiguration manifests primarily when developers or system administrators attempt to inspect PHY registers via the regmap debugfs interface, which is commonly used for diagnostic purposes during development and troubleshooting. When such an inspection occurs, the regmap subsystem attempts to read from the out-of-bounds address specified by max_register. Because this address lies outside the mapped memory region, the kernel triggers a page fault or general protection fault, resulting in a kernel oops. This crash is particularly severe because it occurs while the regmap lock is held. The holding of this mutex during the fatal exception prevents other threads from acquiring the same lock, leading to a system-wide deadlock where subsequent PHY operations are blocked indefinitely. Consequently, not only does the diagnostic tool cause a crash, but the resulting state leaves the hardware interface in an unusable condition until a full system reboot is performed.
From a vulnerability classification perspective, this issue aligns with CWE-125, Out-of-bounds Read, as the software reads data from memory locations beyond the intended buffer or mapped region boundaries. Furthermore, the consequence of holding a lock during a fatal exception that leads to unresponsiveness relates to availability impacts described in ATT&CK technique T1499, Endpoint Denial of Service, although this is an unintentional denial of service caused by a programming error rather than malicious exploitation. The root cause lies in improper resource management and boundary checking within the driver initialization code, which fails to validate that the configured register range fits strictly within the allocated physical memory space provided by the platform's device tree or hardware description.
To mitigate this vulnerability, the primary remediation involves correcting the max_register value in the rockchip-samsung-dcphy driver source code to reflect the actual upper bound of the accessible register block. The correct value should be set to 0xfffc to ensure that all read and write operations remain within the ioremapped memory region. Additionally, developers should implement robust boundary checks when configuring regmap structures for hardware devices to prevent similar off-by-one errors in future updates or related drivers. It is also advisable to review other PHY drivers using similar register mapping configurations to identify potential instances of this same flaw across the kernel codebase. For system administrators encountering systems with this vulnerability, applying a patched version of the Linux kernel that includes this fix is essential to restore stability and prevent accidental crashes during hardware diagnostics.