CVE-2026-80999: net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: realtek: use gpiodsetvaluecansleep for reset GPIO
rtl83xxresetassert() and rtl83xxresetdeassert() are only called from the probe path, which may sleep and is not timing-critical. When the reset GPIO is provided by a sleeping controller such as an I2C I/O expander, gpiodsetvalue() warns:
WARNING: drivers/gpio/gpiolib.c:4030 at gpiodsetvalue+0x44/0x80, CPU#1: kworker/u16:4/61 Hardware name: B&O MAP CA33 Rev f (UNKNOWN) (DT) Workqueue: eventsunbound deferredprobeworkfunc pc : gpiodsetvalue+0x44/0x80 lr : rtl83xxprobe+0x1d8/0x3a0 Call trace: gpiodsetvalue+0x44/0x80 (P) rtl83xxprobe+0x1d8/0x3a0 realtekmdioprobe+0x24/0xa0 mdioprobe+0x38/0x78 reallyprobe+0xc4/0x3e0 driverprobedevice+0x15c/0x1b8 driverprobedevice+0xb4/0x120 deviceattachdriver+0xb8/0x1a0 busforeachdrv+0x88/0xf0 deviceattach+0xa0/0x1d8 deviceinitialprobe+0x54/0x68 busprobedevice+0x38/0xa0 deferredprobeworkfunc+0xb8/0x120 processonework+0x184/0x4e8 workerthread+0x188/0x308 kthread+0x130/0x150 retfromfork+0x10/0x20
Switch both helpers to gpiodsetvaluecansleep() so such a reset GPIO can be used without triggering the warning.
The reset GPIO has been driven with the non-sleeping gpiodsetvalue() since the driver was added in v4.19. The call has since been refactored across several files - from realtek-smi.c / realtek-mdio.c into the common rtl83xx.c module and then into the rtl83xxresetassert() and rtl83xxresetdeassert() helpers (both in v6.9). This patch therefore applies as-is only to kernels that carry those helpers (v6.9+); older stable kernels need the same gpiodsetvaluecansleep() conversion at the corresponding open-coded call sites.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - 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 - Compensating control
In kernels v6.9 and later, switch rtl83xx_reset_assert() and rtl83xx_reset_deassert() from gpiod_set_value() to gpiod_set_value_cansleep(). In older stable kernels, make the same conversion at the corresponding open-coded call sites in realtek-smi.c or realtek-mdio.c.
Event History
Frequently Asked Questions
Which systems are affected in practice?
Systems using the Linux kernel Realtek DSA driver are affected when the switch reset GPIO is supplied by a controller that can sleep, such as an I2C I/O expander. The issue occurs during the driver probe path.
Is this exploitable remotely or does it require attacker interaction?
The provided information describes a kernel warning caused by an unsupported GPIO access method during device probing. It does not describe a remote attack path, required attacker interaction, or privilege requirement.
How can I identify an affected configuration?
An affected system may emit a warning from gpiod_set_value during rtl83xx_probe, with a call trace involving rtl83xx_reset_assert or rtl83xx_reset_deassert. This is specifically relevant when the reset GPIO is backed by a sleeping GPIO controller.
What can be done if the fix cannot be applied immediately?
Avoid configuring the Realtek switch reset GPIO through a sleeping controller such as an I2C I/O expander. The issue does not apply to the described configuration unless such a reset GPIO is used.