CVE-2025-21783

What it actually does

NULL pointer dereference crash in gpiochip_get_ngpios() when chip_*() macros are invoked before gpiodev initialization during bgpio_init() error paths.

Why it matters to the business

Kernel panic or system crash during GPIO device initialization on Linux systems, causing denial of service and potential loss of hardware control functions.

How an attack unfolds

An attacker with local access triggers an error condition in bgpio_init() that reaches gpiochip_get_ngpios(), where uninitialized gpiodev leads to a crash via the chip_*() macros.

How to fix it

Upgrade the Linux kernel to the commit 4d9b2b62e1136d10f661ec4c0c268140b6f74f4f or later stable releases containing the fix that replaces chip_*() macros with dev_*() equivalents.

How to confirm the fix worked

Confirm the running kernel contains commit 4d9b2b62e1136d10f661ec4c0c268140b6f74f4f; test bgpio_init() error paths on affected GPIO hardware to ensure no crash occurs.

Typical attack path

1. Obtain local code execution on a Linux system
2. Load or trigger a driver that calls bgpio_init() and forces an error path
3. Invoke gpiochip_get_ngpios() before gpiodev is set
4. Trigger NULL dereference and kernel crash

How to detect it

Review kernel logs for NULL pointer dereference oops in gpiolib or gpiochip_get_ngpios functions during driver initialization; correlate with bgpio_init calls.

What your security team should do

• Apply the referenced kernel commit or distribution update immediately on all affected systems
• Prioritize systems exposing GPIO interfaces or using bgpio drivers
• Monitor for kernel oops/panic reports related to gpiolib during boot or driver load