CVE-2026-89721: phy: rockchip-samsung-dcphy: fix out-of-range max_register
In the Linux kernel, the following vulnerability has been resolved:
phy: rockchip-samsung-dcphy: fix out-of-range maxregister
The PHY register block is 64KB, so with a register stride of 4 the last accessible register sits at offset 0xfffc. maxregister 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Configuration
Set max_register to 0xfffc, the last accessible register offset in the 64KB PHY register block, instead of 0x10000.
phy: rockchip-samsung-dcphy max_register = 0xfffc
Event History
Frequently Asked Questions
What activity triggers the failure?
Dumping the affected PHY registers through the regmap debugfs interface reads one register beyond the 64KB ioremapped PHY register block. This can cause an oops when the access reaches the unmapped page.
What is the operational impact after the oops?
The oops occurs while the regmap lock is held. Subsequent PHY operations can then deadlock.
How can systems be mitigated before applying the fix?
Avoid using the regmap debugfs interface to dump registers for the affected PHY. The described out-of-range access is triggered by that register-dump operation.