CVE-2026-46222

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel Rockchip Camera Interface driver, rkcif. The driver fails to require that certain media pads are connected before enabling video streams. A local user with access to the affected V4L2 video device can trigger stream enablement through normal video ioctl paths, causing the kernel to dereference a NULL pointer in rkcif_interface_enable_streams. The observed failure is a kernel NULL pointer dereference at address 0x20, which can crash the kernel or destabilize the system. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high availability impact, with no direct confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can cause affected Linux systems using Rockchip camera hardware and the rkcif driver to crash or become unavailable. This is most relevant for embedded devices, edge systems, kiosks, cameras, industrial devices, and appliances that rely on continuous video capture. While there is no indication of remote code execution or data theft, repeated local triggering could interrupt operations, degrade service reliability, and require manual or automated recovery. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no public exploit maturity reported, so urgency is highest for systems exposing local users, containers, applications, or services to V4L2 camera devices.

How an attack unfolds

An attacker first needs local execution privileges on an affected Linux system and access to a Rockchip camera/video device node handled by the rkcif driver, such as a V4L2 device. The attacker then uses video streaming operations, typically through V4L2 ioctls, to request stream start on a media graph where the expected connected subdevice is absent or not validated. Because the rkcif pads are missing the required connection check, the driver proceeds as if a connected device exists. During stream enablement, the kernel reaches rkcif_interface_enable_streams and dereferences a NULL pointer. This results in an oops or panic depending on kernel configuration and system policy, causing a denial of service. Exploitation does not require user interaction and does not require defeating memory corruption protections because the primary impact is availability loss through a kernel crash.

How to fix it

Upgrade to a Linux kernel or vendor-supplied kernel package that includes the upstream fix for the Rockchip rkcif media driver, specifically the change that adds the missing MUST_CONNECT flag/checks to the affected pads. Because no exact fixed versions were provided, use distribution, device vendor, or board-support-package advisories to identify the first patched kernel for the affected product line. Reboot into the patched kernel after installation and verify that the running kernel, not just the installed package, has been updated. If immediate patching is not possible, reduce exposure by restricting access to /dev/video* and media controller devices, removing untrusted users from groups such as video, preventing containers or sandboxed workloads from receiving camera device passthrough, disabling unused camera hardware, blacklisting or unloading the rkcif-related driver where operationally feasible, and limiting local shell access on affected systems.

How to confirm the fix worked

Confirm exposure by checking whether the system is running a Linux kernel build that includes the Rockchip rkcif driver and whether Rockchip camera/video devices are present. Validate remediation by confirming the running kernel version matches a vendor build documented as fixed, then rebooting and retesting normal camera streaming workflows. Review kernel configuration and loaded modules for rkcif or Rockchip CIF support. Access-control validation should confirm that only trusted users and services can open /dev/video* and related media devices. A practical negative test is to verify that malformed or incomplete media-pipeline stream-on attempts no longer produce kernel oops messages referencing rkcif_interface_enable_streams, v4l2_subdev_enable_streams, or vb2_start_streaming.

Typical attack path

1. Gain local code execution or an authenticated local shell on an affected Linux system.
2. Confirm that the system uses Rockchip camera hardware and exposes a V4L2 video device handled by the rkcif driver.
3. Open the relevant /dev/video* device with sufficient permissions.
4. Issue V4L2 stream-on operations against a media pipeline with missing or invalid connected pad state.
5. Trigger the vulnerable rkcif stream enablement path.
6. Cause a kernel NULL pointer dereference in rkcif_interface_enable_streams, resulting in a crash, oops, panic, or service interruption.

How to detect it

Look for evidence of prior exploitation in kernel logs, persistent journal entries, crash dumps, and device health telemetry. Relevant sources include dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-journald kernel logs, pstore/ramoops records, kdump/vmcore artifacts, and monitoring alerts for unexpected reboots or kernel panics. Search for kernel oops or panic records showing a NULL pointer dereference at virtual address 0000000000000020 and call traces containing rkcif_interface_enable_streams, v4l2_subdev_enable_streams, rkcif_stream_start_streaming, vb2_start_streaming, vb2_core_streamon, vb2_ioctl_streamon, v4l_streamon, video_usercopy, or v4l2_ioctl. Correlate crash timestamps with local authentication logs, sudo activity, container starts, application deployments, and accesses to /dev/video* devices. Because exploitation uses legitimate local V4L2 interfaces, there may be no network IOC; detection is primarily host-based and crash-forensics based.

• Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
• rkcif_interface_enable_streams+0x48/0xf0
• rkcif_interface_enable_streams
• v4l2_subdev_enable_streams
• rkcif_stream_start_streaming
• vb2_start_streaming
• vb2_core_streamon
• vb2_ioctl_streamon
• v4l_streamon
• __video_do_ioctl
• video_usercopy
• video_ioctl2
• v4l2_ioctl
• /dev/video
• /sys/class/video4linux
• kernel NULL pointer dereference
• Call trace: rkcif_interface_enable_streams

What your security team should do

• Inventory Linux systems and embedded devices using Rockchip SoCs or Rockchip camera interfaces, prioritizing systems that expose /dev/video* to users, applications, or containers.
• Apply vendor kernel updates that include the rkcif MUST_CONNECT pad validation fix, and ensure systems are rebooted into the patched kernel.
• Until patched, restrict access to video and media devices by tightening device-node permissions, group membership, container device passthrough, and service privileges.
• Monitor kernel logs for NULL pointer dereferences and call traces involving rkcif_interface_enable_streams or V4L2 stream-on paths.
• For embedded or appliance fleets, coordinate with hardware vendors or BSP maintainers if the kernel is not updated through a standard Linux distribution channel.
• Treat repeated local crashes involving the rkcif driver as potentially malicious if they occur near suspicious logins, new local users, container launches, or unusual access to camera devices.