CVE-2026-80999

In the Linux kernel, the following vulnerability has been resolved:

net: dsa: realtek: use gpiod set value cansleep for reset GPIO

rtl83xx reset assert() and rtl83xx reset deassert() 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, gpiod set value() warns:

WARNING: drivers/gpio/gpiolib.c:4030 at gpiod set value+0x44/0x80, CPU#1: kworker/u16:4/61 Hardware name: B&O MAP CA33 Rev f (UNKNOWN) (DT) Workqueue: events unbound deferred probe work func pc : gpiod set value+0x44/0x80 lr : rtl83xx probe+0x1d8/0x3a0 Call trace: gpiod set value+0x44/0x80 (P) rtl83xx probe+0x1d8/0x3a0 realtek mdio probe+0x24/0xa0 mdio probe+0x38/0x78 really probe+0xc4/0x3e0 driver probe device+0x15c/0x1b8 driver probe device+0xb4/0x120 device attach driver+0xb8/0x1a0 bus for each drv+0x88/0xf0 device attach+0xa0/0x1d8 device initial probe+0x54/0x68 bus probe device+0x38/0xa0 deferred probe work func+0xb8/0x120 process one work+0x184/0x4e8 worker thread+0x188/0x308 kthread+0x130/0x150 ret from fork+0x10/0x20

Switch both helpers to gpiod set value cansleep() so such a reset GPIO can be used without triggering the warning.

The reset GPIO has been driven with the non-sleeping gpiod set value() 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 rtl83xx reset assert() and rtl83xx reset deassert() 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 gpiod set value cansleep() conversion at the corresponding open-coded call sites.