CVE-2026-46286

What it actually does

This is a Linux kernel out-of-bounds read in the Qualcomm LPG LED/PWM driver. The driver extracts a 3-bit hardware register value with FIELD_GET(), which can produce values 0 through 7, but uses that value as an index into an array containing only 5 entries. If an unexpected register value is encountered, the kernel can read past the end of the array and use unintended memory as configuration data for LED/PWM chip setup. The most likely technical effects are incorrect device configuration, kernel warnings, instability, or denial of service on systems using the affected Qualcomm LPG driver; reliable privilege escalation or data disclosure is not indicated by the available description.

Why it matters to the business

The business risk is primarily service reliability for Linux systems that include Qualcomm LPG LED/PWM hardware and load the affected driver, such as embedded, mobile, appliance, or specialized ARM-based devices. Affected devices could become unstable, misconfigure LED/PWM behavior, or require reboot/recovery if the driver consumes invalid hardware-derived values. The vulnerability is not listed in CISA KEV, has very low EPSS, and has no reported exploit maturity, so broad internet-scale exploitation is unlikely; however, organizations shipping or operating Qualcomm-based Linux devices should still prioritize kernel updates through normal maintenance because kernel flaws can be difficult to monitor and may affect device availability.

How an attack unfolds

An attacker would first need access to a system where the affected Qualcomm LPG driver is present and active, or to a pathway that can influence the hardware/register state consumed by that driver. During driver initialization or configuration, the driver reads a 3-bit high-resolution selection value from a register. If that value is outside the expected 0-to-4 range, the vulnerable code indexes beyond the valid high-resolution array. The resulting out-of-bounds read supplies unintended data to subsequent chip setup logic, potentially causing malformed LED/PWM configuration or kernel instability. Based on the public description, exploitation depends on uncommon hardware-specific conditions or control over device state rather than a typical remote network request, and there is no evidence of active exploitation or known ransomware use.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the Qualcomm LPG driver bounds check. If using a vendor kernel, obtain the patched kernel from the device, distribution, SoC, or appliance vendor rather than relying only on mainline version numbers. If immediate patching is not possible, reduce exposure by disabling or unloading the Qualcomm LPG LED/PWM driver where it is not required, removing unused LED/PWM device-tree entries from custom builds, or limiting physical/local access to devices where the hardware is present. Rebuild and redeploy affected embedded images after confirming the patch is included in the kernel source used for production firmware.

How to confirm the fix worked

Confirm the running kernel or firmware build includes the qcom-lpg fix that validates the high-resolution selector before indexing the array. For source-based builds, inspect the Qualcomm LPG LED driver and verify that the FIELD_GET-derived selector is checked against the array size before use. On deployed systems, verify the patched kernel package or firmware version is installed, then reboot into the updated kernel. Confirm whether the driver is present or loaded by checking kernel modules, platform drivers, and device-tree configuration for Qualcomm LPG support. If the driver is not present, not loadable, and the hardware is absent, practical exposure is low.

Typical attack path

1. Identify a Linux device using Qualcomm LPG LED/PWM hardware and the vulnerable kernel driver.
2. Obtain local, physical, firmware-level, or device-control access capable of influencing the relevant LPG register state or triggering driver reinitialization under abnormal conditions.
3. Cause the driver to read a high-resolution selector value outside the valid array range.
4. Trigger the vulnerable array lookup during probe, configuration, suspend/resume, or LED/PWM setup paths.
5. Leverage the resulting invalid configuration data to cause device malfunction, kernel instability, or denial of service.

How to detect it

Retrospective exploitation detection is difficult because this flaw does not produce a unique network indicator and may only appear as local kernel instability or abnormal driver behavior. Review kernel logs, crash dumps, pstore/ramoops records, serial console logs, systemd journal entries, and device telemetry for qcom-lpg or leds-qcom-lpg messages, kernel oops/panic traces involving the Qualcomm LPG driver, unexpected reboots during LED/PWM initialization, suspend/resume, or boot, and abnormal LED/PWM behavior preceding a crash. On embedded devices, preserve crash dumps and compare affected timelines against local access, firmware update, hardware manipulation, or test/debug activity. There are no public threat actors or campaigns associated with this vulnerability in the provided data.

• qcom-lpg
• leds-qcom-lpg
• leds-qcom-lpg.ko
• drivers/leds/rgb/leds-qcom-lpg.c
• /sys/bus/platform/drivers/qcom-lpg
• qcom_lpg
• kernel: Oops
• kernel: BUG
• Kernel panic
• ramoops
• pstore

What your security team should do

• Inventory Linux devices, firmware images, and embedded products that use Qualcomm SoCs or include the qcom-lpg LED/PWM driver.
• Prioritize patching for embedded, appliance, mobile, kiosk, IoT, and edge devices where kernel updates are slower and physical/local access is more plausible.
• Coordinate with device and distribution vendors for a kernel or firmware update containing the upstream bounds-check fix.
• If patching is delayed, disable the qcom-lpg driver or associated device-tree nodes where LED/PWM functionality is not operationally required.
• Monitor kernel logs from potentially affected devices for qcom-lpg-related crashes, warnings, or abnormal LED/PWM initialization behavior.
• Treat exploitation likelihood as currently low because there is no KEV listing, no known ransomware association, very low EPSS, and no public exploit maturity, but keep it in regular kernel maintenance scope.