CVE-2021-1906

What it actually does

This vulnerability is a local denial-of-service flaw in Qualcomm Snapdragon firmware/driver handling for GPU memory address deregistration. When an address deregistration operation fails, the failure is not handled correctly, which can leave GPU address-management state inconsistent and cause subsequent GPU address allocations to fail. An attacker with local, low-privileged execution on an affected device may be able to trigger repeated allocation failures or GPU/driver instability, resulting in application crashes, graphics subsystem failure, device hangs, or reboot conditions. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, no confidentiality or integrity impact, and high availability impact.

Why it matters to the business

Successful exploitation can disrupt affected Snapdragon-based devices by degrading or disabling graphics/GPU functionality, causing application failures, system instability, or forced reboots. For mobile, IoT, automotive, industrial, wearable, voice/music, connectivity, and embedded devices, this can translate into service interruption, impaired user experience, operational downtime, safety-adjacent disruption where displays or GPU-backed workloads are important, and increased support or replacement costs. The issue is listed in CISA KEV with a remediation due date of 2021-11-17 and has been reported as exploited in the wild, so organizations should treat unpatched affected firmware as a known-exploited exposure even though the EPSS score is low and stable.

How an attack unfolds

An attacker first obtains local code execution on an affected Snapdragon-based device, such as through a malicious app, compromised local process, chained vulnerability, or physical/debug access path. The attacker then exercises GPU or graphics-driver interfaces in a way that causes address deregistration to fail. Because the firmware/driver does not correctly recover from that failure, internal GPU address-allocation state can become inconsistent. Subsequent allocation attempts fail, destabilizing GPU-backed applications or the graphics subsystem. Repeated triggering can produce a persistent denial-of-service condition until the affected service, driver, or device is reset. In real-world exploitation, this type of flaw is most likely used as part of a chain after initial local execution to disrupt device availability or impair monitoring/user interaction rather than to steal data directly.

How to fix it

Apply the vendor-provided Qualcomm/OEM firmware or operating-system update that contains the fix for CVE-2021-1906. Because Snapdragon firmware updates are commonly delivered through device OEM, carrier, BSP, Android security bulletin, embedded Linux vendor, or automotive/IoT platform update channels, remediation should be tracked by exact device model, chipset, firmware branch, and OEM advisory rather than by package name alone. No fixed versions were provided in the input, so organizations should consult Qualcomm and device-vendor advisories for the applicable patched firmware builds. Where immediate patching is not possible, reduce risk by restricting installation and execution of untrusted local applications, enforcing application allowlisting on managed/embedded devices, disabling unnecessary local/debug access, limiting shell/ADB/JTAG access, and prioritizing patching for devices exposed to untrusted users or running mission-critical GPU/display workloads.

How to confirm the fix worked

Confirm exposure by inventorying devices and firmware that use affected Qualcomm Snapdragon components, then compare chipset, firmware, BSP, Android patch level, and OEM build numbers against Qualcomm and OEM security advisories. Validate remediation by confirming the patched firmware/OS build is installed and that the vendor bulletin including this vulnerability is marked as applied. Functional validation should include exercising graphics/GPU workloads after patching and verifying there are no recurring GPU address-allocation failures, graphics service crashes, kernel warnings, device hangs, or unexpected reboots. For Android-derived platforms, review the security patch level and vendor security patch level; for embedded/automotive/IoT platforms, review the BSP release notes and firmware component versions supplied by the OEM or silicon vendor.

Typical attack path

1. Identify a device using an affected Qualcomm Snapdragon chipset or firmware build.
2. Gain local low-privileged execution on the device through a malicious app, compromised process, physical access, or another vulnerability.
3. Open or interact with GPU/graphics driver interfaces exposed to local processes.
4. Trigger a GPU address deregistration failure condition.
5. Exploit the improper failure handling to corrupt or exhaust GPU address-allocation state.
6. Cause GPU allocation failures, graphics subsystem instability, application crashes, device hangs, or reboot behavior.
7. Optionally repeat the trigger to maintain a denial-of-service condition.

How to detect it

Post-exploitation detection is difficult because the vulnerability causes availability failures and may not create a unique forensic artifact. Focus on endpoint, mobile-device-management, embedded telemetry, kernel logs, Android logcat, crash dumps, watchdog reset records, and system reboot history. Look for repeated GPU/graphics driver allocation failures, KGSL/Adreno driver errors, graphics service crashes, application crashes involving GPU memory allocation, watchdog resets following graphics errors, and clusters of unexplained reboots after installation or execution of a local app. On Android-derived systems, collect logcat buffers, kernel dmesg/pmsg/ramoops logs, tombstones, dropbox entries, and app install/execution history around the time of instability. On embedded Linux or automotive/IoT systems, review persistent kernel logs, systemd journal entries if available, watchdog logs, and vendor crash telemetry. Because known exploitation has been reported, correlate these artifacts with suspicious local code execution, newly installed untrusted applications, abnormal use of GPU device nodes, or attempts to access graphics driver interfaces from unexpected processes.

• /dev/kgsl-3d0
• kgsl
• KGSL
• adreno
• Adreno
• GPU address allocation failure
• address allocation failure
• address deregistration
• deregistration failure
• gpu fault
• GPU fault
• kgsl_sharedmem_alloc
• kgsl_mmu
• kgsl_iommu
• kgsl_drawctxt
• kgsl-3d0
• SurfaceFlinger
• hwui
• libGLES
• watchdog bite
• Watchdog detected hard LOCKUP
• ramoops
• pstore
• /sys/fs/pstore
• /proc/last_kmsg
• /sys/class/kgsl/kgsl-3d0

What your security team should do

• Prioritize identification and remediation of affected Snapdragon-based devices because this is a known-exploited vulnerability listed in CISA KEV, with the historical due date of 2021-11-17 already passed.
• Obtain patched firmware or OS images from the relevant OEM, carrier, BSP provider, or Qualcomm-supported update channel and deploy them to affected models.
• Prioritize devices that permit third-party apps, local user access, physical access, debug access, kiosk interaction, or field operation where denial of service would affect operations.
• If patching is delayed, enforce application allowlisting, remove untrusted apps, disable unnecessary developer/debug interfaces, and restrict local shell access.
• Monitor device telemetry, kernel logs, crash logs, and reboot reasons for GPU/graphics allocation failures or repeated graphics subsystem crashes.
• For managed mobile and embedded fleets, require minimum OS/vendor security patch levels and quarantine or retire devices that cannot receive fixed firmware.
• Assess whether this vulnerability could be chained with other local-code-execution issues in the environment and prioritize hardening accordingly.