CVE-2026-43256

What it actually does

This is a local Linux kernel memory-corruption flaw in the Qualcomm Camera Subsystem VFE interrupt handling path. The vulnerable code iterates over seven image-master entries but uses the same index to access an array that only contains four VFE line entries, causing out-of-bounds memory access for indexes 4 through 6. Because the bug occurs in kernel context, a local user or process able to exercise the affected camera driver path could potentially crash the kernel, corrupt adjacent kernel memory, or, depending on memory layout and exploitability, escalate privileges or disclose sensitive kernel memory.

Why it matters to the business

Affected Linux systems using the Qualcomm camera subsystem may be exposed to local denial of service and potential privilege escalation. The practical business risk is highest for Android, embedded Linux, edge, IoT, mobile, and appliance platforms built on Qualcomm SoCs where untrusted applications or lower-privileged local users can interact with camera functionality. This issue is not listed in CISA KEV, is not reported as ransomware-used, has no known mature public exploit, and has a low EPSS score, so urgency is moderate unless affected devices expose camera access to untrusted code or operate in high-sensitivity environments.

How an attack unfolds

An attacker first needs local code execution or an existing low-privileged foothold on an affected system with the Qualcomm CAMSS VFE driver present and reachable. The attacker then triggers camera/VFE activity that causes the vulnerable interrupt service routine to process register-update events. During that handling, the kernel loop uses indexes beyond the valid vfe->line[] array bounds, producing an out-of-bounds access in kernel memory. A simple exploitation attempt may cause a kernel oops, panic, or device reboot. A more advanced attacker would attempt to shape surrounding kernel memory and repeatedly trigger the condition to turn the out-of-bounds access into controlled memory corruption, potentially leading to privilege escalation or kernel information disclosure. There is currently no public indication in the provided data that this vulnerability is being exploited in the wild.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the Qualcomm CAMSS VFE interrupt handling logic, specifically the change that separates iteration over VFE output lines from iteration over image write masters so vfe->line[] is not indexed out of bounds. No exact fixed package versions were provided, so use the fixed kernel version or vendor security advisory applicable to the distribution, device vendor, Android BSP, or embedded Linux platform in use. Where immediate patching is not possible, reduce exposure by disabling unused camera functionality, disabling or unloading the affected qcom-camss driver where operationally acceptable, restricting access to video/camera device nodes to trusted users and services only, and limiting the ability of untrusted applications or containers to access host camera devices.

How to confirm the fix worked

Confirm the running kernel includes the fix by checking the vendor kernel changelog, distribution security advisory, or source tree for the corrected CAMSS VFE loop logic in the media/qcom/camss VFE code. Validate that affected systems are no longer running vulnerable kernel builds after reboot. On source-based or embedded builds, inspect the patched code path to ensure vfe_isr() no longer uses MSM_VFE_IMAGE_MASTERS_NUM as the loop bound when indexing vfe->line[]. Confirm whether the affected driver is present or active by checking loaded modules, kernel configuration, device tree support, and camera device nodes. Functional validation should include exercising camera workloads while monitoring kernel logs for oops, KASAN, UBSAN, panic, or qcom-camss related errors.

Typical attack path

1. Gain local execution on an affected Linux device, for example as an unprivileged user or sandboxed application.
2. Confirm the affected Qualcomm CAMSS/VFE camera driver is loaded, built into the kernel, or reachable through camera device interfaces.
3. Interact with camera functionality or device nodes to cause VFE register-update interrupt handling to occur.
4. Trigger the vulnerable vfe_isr() path so indexes 4, 5, or 6 are passed into vfe_isr_reg_update() against a four-entry line array.
5. Observe or exploit the resulting out-of-bounds kernel memory access, commonly causing instability and potentially enabling privilege escalation with additional exploit engineering.
6. Use elevated privileges, if achieved, to disable defenses, access sensitive data, or establish persistence.

How to detect it

There are no unique network indicators for this vulnerability because exploitation requires local interaction with a kernel camera driver path. To assess possible prior exploitation, review kernel logs, persistent crash logs, Android tombstones/last_kmsg/pstore records, systemd journal entries, and EDR telemetry for kernel oops, panic, KASAN, UBSAN, or general protection fault messages involving qcom-camss, CAMSS VFE, vfe_isr(), or vfe_isr_reg_update(). Look for repeated camera-service crashes, unexplained reboots during camera use, or local processes opening video/camera device nodes shortly before kernel faults. On Android-derived platforms, correlate camera HAL logs, mediaserver/cameraserver events, application camera access records, and kernel crash dumps. Because no public exploit maturity or threat actor activity is indicated, detections should focus on abnormal local triggering patterns and kernel memory-corruption evidence rather than known exploit payloads.

• vfe_isr_reg_update
• vfe_isr
• qcom-camss
• camss
• CAMSS
• VFE
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• UBSAN: array-index-out-of-bounds
• kernel BUG
• Oops:
• general protection fault
• Kernel panic
• pstore
• last_kmsg
• /dev/video
• /dev/media

What your security team should do

• Inventory Linux, Android, embedded, edge, and appliance platforms using Qualcomm SoCs and the qcom-camss camera subsystem.
• Prioritize patching systems where untrusted local users, apps, containers, or browser/media workflows can reach camera devices.
• Obtain fixed kernel builds from the OS, device, SoC, or BSP vendor and schedule deployment with reboot validation.
• If patching is delayed, restrict permissions on camera and video device nodes and remove camera access from untrusted workloads.
• Disable or unload the affected camera driver on systems that do not require camera functionality, after confirming operational impact.
• Monitor kernel logs for crashes, KASAN/UBSAN findings, and qcom-camss/VFE errors that may indicate attempted triggering or instability.
• Treat suspicious local privilege escalation activity on affected devices as potentially related, even though no public exploitation is indicated by the provided intelligence.
• Track vendor advisories for exact fixed versions because none were provided in the input.