UBUNTU-CVE-2026-80999: Low severity ubuntu/linux-hwe-edge vulnerability
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
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
Replace gpiod_set_value() with gpiod_set_value_cansleep() in rtl83xx_reset_assert() and rtl83xx_reset_deassert(); on kernels older than v6.9, apply the same conversion at the corresponding open-coded reset GPIO call sites.
Linux kernel Realtek DSA driver Reset GPIO API calls = gpiod_set_value_cansleep()
Event History
Frequently Asked Questions
Which systems are most likely to encounter this issue?
Systems using a Realtek DSA switch whose reset GPIO is supplied by a sleeping GPIO controller, such as an I2C I/O expander, are affected during driver probing. The issue is associated with the rtl83xx reset assert and deassert paths.
How can I tell whether a system is affected?
Affected systems may log a WARNING from gpiod_set_value() during probe or deferred probe work. Relevant call traces include rtl83xx_probe, realtek_mdio_probe, and deferred_probe_work_func.
Does the reset operation require the non-sleeping GPIO API?
No. The reset helpers are called only from the probe path, where sleeping is allowed, and the reset operation is not timing-critical. Using the sleep-capable GPIO setter allows reset GPIOs on sleeping controllers to be used without the warning.