CVE-2023-33107

What it actually does

This is a local memory-corruption vulnerability in Qualcomm Graphics Linux components triggered during an IOCTL operation that assigns a shared virtual memory region. A low-privileged local process that can reach the vulnerable graphics device interface may be able to corrupt kernel/driver memory. Successful exploitation can result in kernel-level code execution, privilege escalation, information disclosure, or device crash/reboot. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Compromise of affected Qualcomm-based devices can allow an attacker who has already gained local code execution to take control of the device at a deeper privilege level, bypass application sandboxing, tamper with data, disable security controls, or cause outages through crashes. Because this vulnerability is listed in CISA KEV and has observed in-the-wild exploitation, remediation should be treated as urgent; the KEV remediation deadline of 2023-12-26 has long passed. Impact is especially relevant for fleets of Android, Linux, IoT, automotive, or embedded systems using affected Qualcomm chipsets or firmware where patching may depend on OEM firmware releases.

How an attack unfolds

An attacker first needs a way to run code locally on an affected device, such as through a malicious application, compromised service, chained browser/app exploit, or prior foothold. The attacker then opens the exposed Qualcomm graphics device interface and sends a crafted IOCTL related to shared virtual memory assignment. Malformed memory-region parameters cause the graphics driver to corrupt kernel memory. A reliable exploit typically combines this corruption with heap grooming, memory spraying, and kernel address-disclosure or bypass techniques to overwrite sensitive kernel structures or control-flow targets. Once kernel privileges are obtained, the attacker can escape app sandboxes, access protected files, tamper with running processes, install persistence where feasible, conceal activity, or use the device as a platform for further collection and lateral activity. Public reporting and KEV status indicate real-world exploitation, although no reliable named threat actor attribution is established from the supplied data.

How to fix it

Apply the relevant Qualcomm/OEM firmware, BSP, kernel, Android security bulletin, or embedded Linux update that contains the vendor fix for CVE-2023-33107. No exact fixed versions were supplied, so remediation should be validated against the device OEM advisory, Qualcomm security bulletin, carrier image, Android security patch level, or product firmware release notes for the specific chipset and product line. Prioritize affected internet-managed, high-value, mobile, IoT, automotive, and embedded devices because this vulnerability is in CISA KEV and has active exploitation. Where immediate patching is not possible, reduce exposure by preventing installation or execution of untrusted local code, enforcing application allowlisting, keeping SELinux/AppArmor or equivalent MAC controls enabled and enforcing, restricting access to graphics device nodes to only required trusted users/groups, disabling unnecessary debug interfaces, and monitoring for kernel crashes or suspicious access to Qualcomm graphics interfaces. For embedded products, request patched firmware from the OEM or silicon integrator and plan image rebuild/redeployment if the affected driver is included in a custom Linux build.

How to confirm the fix worked

Confirm exposure by inventorying devices and firmware that use affected Qualcomm chipsets or graphics Linux components, then map each device to the OEM or Qualcomm advisory. Validate remediation by checking installed firmware/OS build numbers, Android security patch levels where applicable, kernel package versions, vendor BSP revisions, and release notes showing inclusion of the fix. Confirm that vulnerable images are no longer deployed in golden images, OTA channels, containers, or embedded firmware bundles. On Linux-based systems, verify the presence and permissions of Qualcomm graphics device interfaces such as KGSL/Adreno nodes and confirm untrusted users cannot access them unnecessarily. Perform a controlled reboot and review kernel logs for recurring graphics-driver faults. If vulnerability scanners or mobile-device-management tools support this CVE, run authenticated checks and verify they report the device as patched or not applicable.

Typical attack path

1. Gain local code execution on an affected Qualcomm-based device, often through a malicious app, compromised process, or exploit chain.
2. Identify that the vulnerable Qualcomm graphics driver/device interface is present and accessible to the process.
3. Open the graphics device node or driver interface used for IOCTL communication.
4. Submit crafted shared-virtual-memory IOCTL parameters that trigger memory corruption in the graphics driver.
5. Use heap grooming or memory-spray techniques to shape corrupted kernel memory into a controlled primitive.
6. Escalate privileges by modifying kernel credentials, bypassing sandbox controls, or redirecting kernel execution flow.
7. Execute post-exploitation actions such as data access, security-control disabling, persistence, surveillance, or device disruption.

How to detect it

Detection should focus on signs of prior local privilege escalation and graphics-driver instability because exploitation occurs through a local IOCTL and may leave limited network evidence. Review kernel logs, dmesg, journalctl, Android logcat, pstore/ramoops crash records, MDM/EDR telemetry, and device crash analytics for Qualcomm graphics/KGSL/Adreno faults near suspicious app execution. Look for repeated kernel oops, panic, page fault, slab corruption, KASAN, or use-after-free messages involving graphics drivers or IOCTL handling. Correlate graphics-driver crashes with unexpected privilege changes, SELinux/AppArmor denials, execution of root shells, remount attempts, modification of system partitions, installation of unknown privileged services, or tampering with security tooling. On Android-like systems, examine logcat events, tombstones, kernel panic reports, suspicious APK installation times, and processes accessing /dev/kgsl-3d0 before crashes. On embedded Linux systems, inspect audit logs for untrusted users opening Qualcomm graphics device nodes and for anomalous processes issuing large volumes of IOCTLs. Absence of these artifacts does not prove non-exploitation, especially if logs rotate or the attacker gained kernel privileges and cleaned evidence.

• /dev/kgsl-3d0
• kgsl
• adreno
• IOCTL_KGSL
• Unable to handle kernel NULL pointer dereference
• Unable to handle kernel paging request
• Internal error: Oops
• Kernel panic - not syncing
• BUG: KASAN: use-after-free
• BUG: KASAN: slab-out-of-bounds
• general protection fault
• slab corruption
• ramoops
• pstore
• avc: denied
• init: starting service 'su'
• remount,rw /system
• /data/tombstones/
• /sys/fs/pstore/console-ramoops
• /sys/fs/pstore/dmesg-ramoops

What your security team should do

• Treat this as high priority because it is in CISA KEV, has active in-the-wild exploitation, and the federal remediation due date has passed.
• Build an inventory of Qualcomm-based devices, firmware images, mobile builds, IoT products, and embedded Linux distributions that include Qualcomm Graphics Linux components.
• Obtain and deploy OEM or Qualcomm-provided patched firmware/OS updates; do not rely on upstream package updates alone for sealed mobile or embedded devices.
• Prioritize devices that allow third-party apps, process untrusted content, are field-deployed, or are difficult to physically recover after compromise.
• Restrict access to graphics device nodes and debug interfaces wherever operationally feasible until patching is complete.
• Monitor kernel, crash, MDM/EDR, and device-health telemetry for graphics-driver crashes, suspicious IOCTL activity, privilege escalation, or unexpected root access.
• Hunt for signs of exploit chaining, especially recent local app compromise followed by kernel crashes, SELinux denials, root-level process creation, or persistence attempts.
• Require OEM attestation or release-note evidence that the fix is included for any vendor-supplied firmware before approving deployment.
• For products under development, update Qualcomm BSP/vendor blobs and retest graphics, camera, display, and GPU workloads after applying the fix.