CVE-2026-45978

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel Greybus lights staging driver. During light configuration, the driver records a non-zero channel count before successfully allocating the channel array. If the allocation fails, the release path iterates over the recorded channel count and dereferences a NULL channels pointer, causing a kernel NULL pointer dereference. The likely result is a kernel oops or panic, depending on kernel configuration and panic-on-oops settings, leading to service disruption or system crash. The flaw does not provide confidentiality or integrity impact based on the published details.

Why it matters to the business

Systems that load and expose the affected Greybus lights driver could be crashed by a local authenticated user or local process, causing downtime for affected devices or workloads. The risk is reduced by the local-access requirement, low EPSS score, no known public exploit maturity, and no CISA KEV listing, but it can still matter for multi-user Linux systems, embedded devices, development systems, or environments where untrusted local code can run. Because this is in a staging driver, exposure is likely limited to systems that compile, load, or ship the Greybus lights component.

How an attack unfolds

An attacker first needs local code execution or an authenticated local session on a system using an affected Linux kernel with the Greybus lights staging driver available and reachable. The attacker then triggers the Greybus lights configuration path in a way that causes allocation of the channels array to fail after the driver has already stored a non-zero channel count. When the driver unwinds and calls the release routine, the cleanup code trusts the stored count and walks the channels pointer even though allocation failed and the pointer is NULL. This causes a kernel NULL pointer dereference, producing a kernel oops or panic and denying service to the host or device. There is no current indication from the provided intelligence that this vulnerability is being exploited by named threat actors or ransomware campaigns.

How to fix it

Update to a Linux kernel build that includes the upstream fix for the Greybus lights driver: allocate the channels array before publishing channels_count so the cleanup path cannot walk a NULL pointer. Because no exact fixed package versions were provided, use the fixed kernel versions supplied by the relevant Linux distribution, device vendor, or upstream stable kernel branch once available. If immediate patching is not possible, reduce exposure by disabling or not loading the Greybus lights staging driver where it is not required, removing the module from deployed kernel builds, blacklisting the module, restricting local shell access, and limiting the ability of untrusted users or workloads to interact with Greybus-related device interfaces. Where operationally acceptable, configure crash recovery to reduce downtime, but do not treat reboot automation as a substitute for patching.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or source tree includes the Greybus lights fix that allocates the channels array before setting channels_count in gb_lights_light_config(). On packaged distributions, verify the installed kernel version against the vendor advisory or changelog for this vulnerability. On custom kernels, inspect the relevant Greybus lights driver source and confirm the corrected allocation/order-of-assignment logic is present. Validate exposure by checking whether the Greybus lights driver is compiled into the kernel or available as a loadable module, whether it is currently loaded, and whether Greybus-related device interfaces are accessible to local users. After patching or mitigation, confirm the system is booted into the updated kernel and that the vulnerable module is absent, unloaded, or fixed.

Typical attack path

1. Gain local access to a Linux system where the affected Greybus lights staging driver is present, loaded, or otherwise reachable.
2. Interact with the Greybus lights functionality through the available local interface or device path.
3. Trigger the vulnerable light configuration path while inducing or relying on memory allocation failure for the channels array.
4. Cause the cleanup path to execute with a non-zero channel count and a NULL channels pointer.
5. Crash the kernel through a NULL pointer dereference, resulting in denial of service or reboot depending on system configuration.

How to detect it

To determine whether this was already exploited or triggered, review kernel and system logs for oops, panic, NULL pointer dereference, or general protection fault messages referencing the Greybus lights driver or functions such as gb_lights_light_config and gb_lights_release. Relevant sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, persistent pstore/ramoops records, crash dumps, kdump/vmcore artifacts, and hypervisor or device management logs that record unexpected reboots. Investigate suspicious timing correlations between local user sessions, container or workload execution, Greybus device interaction, memory pressure events, and abrupt reboots. Because the vulnerability is a crash condition rather than a code-execution primitive, detection is primarily based on kernel crash artifacts and function names in stack traces rather than durable attacker-created files. Absence of these strings does not prove non-exploitation if kernel logs were not persisted or crash dumps were not collected.

• gb_lights_light_config
• gb_lights_release
• greybus lights
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic - not syncing
• RIP: gb_lights_release
• RIP: gb_lights_light_config
• Call Trace: gb_lights_release
• Call Trace: gb_lights_light_config
• Unable to handle kernel NULL pointer dereference
• /sys/module/greybus
• /sys/module/gb_lights
• gb_lights

What your security team should do

• Inventory Linux systems and embedded devices to determine whether the Greybus lights staging driver is compiled, packaged, or loaded.
• Prioritize patching systems that allow local user access, run untrusted workloads, or expose Greybus functionality.
• Apply vendor-provided kernel updates as they become available; for custom kernels, backport the upstream Greybus lights fix.
• If the driver is not required, disable or blacklist it and remove it from custom kernel configurations.
• Monitor kernel logs for NULL pointer dereferences or oops/panic events involving Greybus lights functions, especially gb_lights_light_config and gb_lights_release.
• Restrict local access and device-interface permissions on systems where patching is delayed.
• Review kernel panic-on-oops and automatic reboot settings to balance availability and forensic preservation requirements.