CVE-2026-46239

What it actually does

This Linux kernel flaw is a local availability vulnerability in the ov5647 media I2C camera sensor driver. When specific V4L2 controls are set, the driver can return from the control handler without releasing a runtime power-management reference via pm_runtime_put(). Repeatedly exercising the affected control paths can leak runtime PM references, leaving the device in an incorrect powered state and potentially causing resource exhaustion, battery drain, device instability, or denial of service. The affected control cases are AUTOGAIN, EXPOSURE_AUTO, and ANALOGUE_GAIN. Exploitation requires local access and privileges sufficient to interact with the camera/video device node; it does not provide confidentiality or integrity impact by itself.

Why it matters to the business

Systems using the affected Linux kernel driver for ov5647 camera hardware may experience degraded reliability, excessive power consumption, camera malfunction, or local denial of service. This is most relevant to embedded Linux devices, Raspberry Pi-style camera deployments, appliances, robotics, kiosks, IoT systems, and battery-powered platforms that expose camera controls to local users or applications. The vulnerability is not currently listed in CISA KEV, has very low EPSS, and has no known public exploit maturity, so broad remote exploitation is unlikely; however, affected devices with untrusted local workloads or user-accessible camera interfaces should still be patched during normal kernel maintenance cycles.

How an attack unfolds

An attacker first obtains local code execution or an interactive account on a system with the ov5647 camera driver loaded and access to the relevant V4L2 device node, such as /dev/video*. The attacker then repeatedly issues camera control changes for affected controls such as autogain, auto exposure, or analogue gain using V4L2 interfaces or tools such as v4l2-ctl. Due to the faulty control-flow path in the driver, each affected operation can increment or retain a runtime PM reference without the matching release. Over time, the leaked references prevent normal power-management state transitions and may cause the camera subsystem or broader device to remain powered, consume resources, behave erratically, or become unavailable. The likely objective is disruption rather than data theft or privilege escalation.

How to fix it

Update to a Linux kernel version or vendor kernel package that includes the ov5647 driver fix changing the affected control paths so pm_runtime_put() is always executed before function exit. Because no exact fixed package versions were provided, use distribution, device-vendor, or upstream stable-kernel advisories to identify the corrected kernel for each platform. Where immediate patching is not possible, reduce exposure by restricting access to camera device nodes such as /dev/video*, limiting membership in groups such as video, disabling or unloading the ov5647 driver if the camera is not required, disabling the camera interface in device configuration where feasible, and preventing untrusted local workloads from accessing V4L2 controls.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel or vendor kernel package includes the ov5647 runtime PM refcount leak fix. On source-based builds, inspect the ov5647 driver control handler and confirm the affected AUTOGAIN, EXPOSURE_AUTO, and ANALOGUE_GAIN cases no longer return directly before the runtime PM release path. On deployed systems, confirm the ov5647 driver is either not loaded, not present, or updated. Validate access controls by checking permissions and group ownership on /dev/video* devices. Functional testing can include repeatedly setting the affected V4L2 controls while monitoring runtime PM state, device suspend/resume behavior, kernel logs, and power consumption to confirm references no longer accumulate.

Typical attack path

1. Gain local access to a Linux system using the ov5647 camera sensor driver.
2. Confirm that the ov5647 driver is present and that a V4L2 video device is accessible.
3. Use V4L2 APIs or command-line tooling to repeatedly set AUTOGAIN, EXPOSURE_AUTO, or ANALOGUE_GAIN controls.
4. Trigger repeated runtime PM reference leaks in the ov5647 control handler.
5. Cause persistent device power-management imbalance, excessive power use, camera malfunction, or local denial of service.

How to detect it

Look for evidence that a local user or process repeatedly manipulated ov5647 camera controls shortly before camera instability, power-management issues, or device unavailability. Useful sources include auditd or eBPF syscall telemetry for access to /dev/video* devices, process execution logs for V4L2 tools, shell history on managed systems, kernel logs from dmesg or journald, embedded device telemetry, power-management logs, and application logs from software that controls cameras. Search for repeated VIDIOC_S_CTRL or VIDIOC_S_EXT_CTRLS activity involving autogain, auto exposure, or analogue gain. Kernel logs may not explicitly record the refcount leak, so detection is circumstantial: correlate high-frequency camera-control changes with ov5647 driver messages, failed suspend/resume behavior, elevated power consumption, or camera service failures. No known threat actors or ransomware campaigns are currently associated with this vulnerability.

• ov5647
• /dev/video
• /dev/video0
• /dev/video1
• v4l2-ctl --set-ctrl
• autogain=
• auto_exposure=
• analogue_gain=
• VIDIOC_S_CTRL
• VIDIOC_S_EXT_CTRLS
• V4L2_CID_AUTOGAIN
• V4L2_CID_EXPOSURE_AUTO
• V4L2_CID_ANALOGUE_GAIN
• pm_runtime
• runtime PM
• media: i2c: ov5647

What your security team should do

• Inventory Linux systems and embedded devices that use ov5647 camera hardware or load the ov5647 kernel module.
• Prioritize patching for devices that allow local users, containers, applications, kiosks, or untrusted workloads to access camera devices.
• Upgrade affected systems to a vendor-supported kernel containing the ov5647 runtime PM fix.
• Restrict /dev/video* access to only trusted users and services; review membership in video or equivalent device-access groups.
• Disable or unload the ov5647 driver on systems where the camera is not operationally required.
• Monitor for unusual repeated V4L2 control changes, camera instability, excessive power draw, suspend/resume failures, or kernel messages referencing ov5647 or runtime PM.
• For embedded fleets, include the corrected kernel in the next firmware image and validate power-management behavior during regression testing.