CVE-2026-93274 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: bcm2835: Don't remove an unregistered GPIO chip
If the devm_pinctrl_register() function fails, bcm2835_pinctrl_probe() calls gpiochip_remove() before gpiochip_add_data() has registered the GPIO chip.
This means that upon failure the gpio_chip.gpiodev is NULL resulting in a null pointer dereference inside the gpiochip_remove() function.
Remove the unnecessary function call to gpiochip_remove(). No GPIO cleanup is required because the GPIO chip has not yet been registered. Without this change there is potential for a kernel panic upon registration failure
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The bcm2835 pinctrl driver in the Linux kernel contains a logic error during its initialization sequence that can lead to a null pointer dereference and subsequent system instability. This vulnerability arises from an incorrect handling of resource cleanup when the primary device management function, devm_pinctrl_register(), fails to allocate or initialize resources successfully. In standard Linux kernel programming patterns using managed resources (devm), drivers are expected to rely on automatic cleanup mechanisms provided by the framework rather than manually invoking removal functions for structures that were never fully established. The specific flaw occurs in the bcm2835_pinctrl_probe() function, which attempts to perform a rollback operation by calling gpiochip_remove() immediately after detecting a failure from devm_pinctrl_register().
The technical root cause lies in the state of the GPIO chip structure at the point of failure. When devm_pinctrl_register() fails, it indicates that the pin control subsystem could not be initialized, which typically precedes or prevents the successful registration and addition of the associated GPIO chip via gpiochip_add_data(). Consequently, the gpiodev pointer within the gpio_chip structure remains NULL because the device has never been officially registered with the kernel's GPIO subsystem. By invoking gpiochip_remove() on this unregistered and uninitialized state, the driver attempts to access memory through a null pointer. This action triggers a null pointer dereference exception within the kernel space, leading to an immediate kernel panic or system crash if not caught by higher-level fault handlers, though such crashes are generally fatal for system availability.
From a security perspective, this vulnerability is classified under CWE-476: NULL Pointer Dereference, which describes situations where software attempts to use a pointer that references memory no longer valid or never allocated. In the context of kernel development, null pointer dereferences can sometimes be leveraged by local attackers with low privileges to cause denial-of-service conditions by triggering system reboots. While this specific issue is primarily an availability concern rather than a direct privilege escalation vector due to the timing during driver probe (which usually requires root or hardware access), it represents a significant reliability flaw in the kernel's error handling path. The vulnerability aligns with ATT&CK technique T1499: Endpoint Denial of Service, as the successful exploitation results in the disruption of service on the affected device by causing a system crash.
The operational impact of this bug is limited to systems using Broadcom BCM2835 hardware during their boot or module initialization phase where pin control registration fails for any reason, such as missing firmware, incompatible device tree configurations, or resource exhaustion. In these scenarios, instead of gracefully failing and allowing the rest of the system to continue operating with a non-functional pinctrl driver, the kernel panics. This results in a complete loss of availability for the embedded device until it is manually rebooted. For devices that rely on continuous operation without user intervention, such as industrial controllers or IoT gateways based on Raspberry Pi Compute Modules or similar BCM2835-based hardware, this can lead to significant downtime and operational disruption.
The resolution involves removing the erroneous call to gpiochip_remove() from the error handling path of bcm2835_pinctrl_probe(). Since devm_pinctrl_register() is a managed resource function, any resources allocated prior to its failure are automatically released by the kernel's device management framework when the probe function returns an error code. Therefore, manual cleanup via gpiochip_remove() is not only unnecessary but harmful because it assumes ownership of a structure that was never fully claimed or registered. By eliminating this redundant and dangerous call, the driver adheres to proper devm usage patterns, ensuring that failure states are handled gracefully without attempting to operate on uninitialized data structures. This fix ensures that if pin control registration fails, the system remains stable, allowing administrators to diagnose configuration issues rather than dealing with a crashed kernel.