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
Linux kernelto a version that resolves this vulnerability.Fixed in v6.9+Patch net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO - Configuration
Replace the reset GPIO non-sleeping call gpiod_set_value() with gpiod_set_value_cansleep() so the sleeping GPIO controller can be used without triggering the warning.
Realtek DSA (rtl83xx/realtek-mdio/realtek-smi) reset GPIO handling = Switch from gpiod_set_value() to gpiod_set_value_cansleep() for the reset GPIO (sleep-capable controller) in probe path (and related reset assert/deassert helpers where applicable)
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.