CVE-2026-43312

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel ov5647 V4L2 camera sensor driver. The driver initializes controls before initializing the V4L2 I2C sub-device state; if an error path is reached during control initialization, the driver may call v4l2_get_subdevdata() before the backing i2c_client has been associated. That can lead to an invalid pointer dereference or kernel oops during device probe or driver initialization. The primary impact is availability loss: depending on kernel panic settings and platform configuration, the result may range from failure of the camera device to a full system crash or reboot. The CVSS vector indicates local access with low attack complexity and low privileges, with no confidentiality or integrity impact expected.

Why it matters to the business

Systems using Linux kernels with the affected ov5647 camera sensor driver may be vulnerable to local crashes when the driver is initialized or forced through the vulnerable error path. This is most relevant to embedded Linux, IoT, robotics, appliance, edge, kiosk, and camera-enabled platforms that include or load the ov5647 driver. Exploitation could interrupt video capture, degrade device reliability, trigger watchdog resets, or cause system downtime. Although this is not known to be exploited in the wild, is not in the CISA KEV catalog, and has a very low EPSS score, the operational impact can still be significant for fleets where camera availability or device uptime is business-critical.

How an attack unfolds

An attacker first needs local access to a system running an affected Linux kernel where the ov5647 driver is present and reachable, typically through a platform using an OV5647-compatible camera sensor or a configuration that causes the driver to probe. The attacker then causes the ov5647 driver to initialize under conditions that make ov5647_init_controls() hit its error-handling path before v4l2_i2c_subdev_init() has associated the I2C client with the sub-device. When the driver attempts to retrieve sub-device data that has not yet been initialized, the kernel can dereference invalid state and generate an oops or panic. If kernel.panic or watchdog behavior is configured to reboot on panic, exploitation may cause a repeatable reboot cycle; otherwise, it may leave the camera subsystem unusable until recovery. No remote network exploitation, privilege escalation, data theft, or code execution is indicated by the available details.

How to fix it

Update to a Linux kernel version that contains the ov5647 fix which initializes the V4L2 I2C sub-device before creating controls. No exact fixed package versions were provided in the input, so use the affected distribution, vendor, board support package, or upstream stable kernel advisory to identify the first fixed release for each deployed kernel branch. Where immediate patching is not possible, mitigate by disabling or blacklisting the ov5647 driver if the camera sensor is not required, removing unused camera overlays/device-tree entries, restricting local shell access and module-loading capability, and ensuring only trusted administrators can alter kernel modules, device-tree overlays, or media/I2C device configuration. For embedded products, rebuild and redeploy kernel images or vendor BSPs with the corrected driver initialization order.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel or vendor kernel package includes the ov5647 patch that calls v4l2_i2c_subdev_init() before ov5647_init_controls(). Check the active kernel version, vendor changelog, source package, or driver source for the corrected probe initialization order. On systems where the driver is used, validate that the OV5647 camera probes successfully without kernel oops messages and that video capture continues to operate after reboot. On systems where the driver is not needed, confirm that the ov5647 module is absent, blacklisted, or not loaded, and that no device-tree overlay or hardware configuration causes it to probe. Exposure can be checked by searching kernel configuration and runtime module state for ov5647 support.

Typical attack path

1. Obtain local access to a Linux system that includes the affected ov5647 kernel driver.
2. Confirm that the ov5647 driver is built into the kernel or available as a loadable module and that the platform can trigger driver probe.
3. Trigger camera sensor probing or driver loading through normal device initialization paths, module loading, device-tree overlay changes, or media/I2C subsystem interactions available to the attacker.
4. Induce or rely on an initialization error condition during ov5647_init_controls() before V4L2 I2C sub-device initialization completes.
5. Cause the driver to access uninitialized sub-device data, resulting in a kernel oops, device failure, panic, reboot, or availability degradation.

How to detect it

To determine whether this was already triggered, review kernel and system logs for oops, panic, NULL pointer dereference, general protection fault, or probe failure messages involving the ov5647 driver and V4L2/I2C camera initialization. Useful log sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, persistent pstore/ramoops records, crash dumps, kdump vmcore metadata, watchdog reboot logs, and embedded device boot logs. Focus on events during boot, camera initialization, driver/module load, media device enumeration, or shortly before unexplained reboots. Look for call traces mentioning ov5647_init_controls(), ov5647_probe(), v4l2_get_subdevdata(), v4l2_i2c_subdev_init(), or the ov5647 module. Also correlate local user activity, module load attempts, device-tree overlay changes, camera service restarts, or media/I2C probing commands immediately before kernel faults. Because the bug causes a crash rather than a durable compromise, forensic evidence is likely limited to kernel logs, crash dumps, reboot records, and operational telemetry rather than files dropped by an attacker.

• ov5647
• ov5647_init_controls
• ov5647_probe
• v4l2_get_subdevdata
• v4l2_i2c_subdev_init
• Unable to handle kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• Call Trace:
• Modules linked in: ov5647
• probe of * failed
• ov5647: probe failed
• /sys/module/ov5647
• /lib/modules/*/kernel/drivers/media/i2c/ov5647.ko
• /var/lib/systemd/pstore
• /sys/fs/pstore
• ramoops
• watchdog: watchdog0: watchdog did not stop

What your security team should do

• Prioritize patching for embedded, edge, camera-enabled, and appliance systems where OV5647 camera availability or device uptime is operationally important.
• Inventory Linux systems for the ov5647 driver by checking kernel modules, kernel configuration, device-tree overlays, and loaded media/I2C devices.
• Apply vendor kernel, distribution kernel, or BSP updates that include the corrected ov5647 initialization order; track fixed versions per kernel branch because no universal package version is provided.
• If the OV5647 camera is not required, disable or blacklist the ov5647 driver and remove unused camera overlays to reduce attack surface.
• Restrict local access, kernel module loading, and device-tree or hardware configuration changes to trusted administrators only.
• Review kernel logs for historical oops, panic, or probe-failure messages involving ov5647, v4l2_get_subdevdata(), ov5647_init_controls(), or ov5647_probe().
• For products with watchdog reboot behavior, investigate unexplained reboot loops or camera initialization failures after boot as potential exploitation or instability indicators.
• Treat this as lower internet-wide exploitation priority because it is local-only, not KEV-listed, has no known exploit maturity, and has a low EPSS score; nevertheless, include it in regular kernel maintenance cycles.