CVE-2026-43162

What it actually does

This flaw is a local denial-of-service vulnerability in the Linux kernel Tegra video driver. In __tegra_channel_try_format(), an allocated V4L2 subdevice state object is not freed on certain v4l2_subdev_call() failure paths. A local user with access to the affected media/video device interface can repeatedly trigger the failing format-negotiation path, causing kernel memory to be leaked over time. Successful exploitation can degrade system stability and may eventually exhaust memory, leading to application failures, service disruption, or a system crash. The issue does not directly provide confidentiality or integrity impact and is not remotely exploitable based on the published vector.

Why it matters to the business

Systems using affected Linux kernels with NVIDIA Tegra video/media functionality may become unstable or unavailable if a local user or compromised local process repeatedly triggers the vulnerable code path. The operational risk is highest for embedded, edge, robotics, camera, IoT, kiosk, and appliance-like systems where Tegra video hardware is enabled and uptime is important. The CVSS availability impact is high, but current public exploitation indicators are low: EPSS is 0.00128, unchanged over 30 days, it is not listed in CISA KEV, and no mature exploit is reported.

How an attack unfolds

An attacker first needs local execution privileges on a system running an affected Linux kernel with the Tegra video driver present and accessible. The attacker then interacts with the V4L2/media device interface and invokes format negotiation or try-format operations that reach __tegra_channel_try_format(). By supplying conditions that cause v4l2_subdev_call() to fail along the vulnerable error paths, the kernel returns without freeing the allocated sd_state object. Repeating this operation leaks kernel memory incrementally. Over time, accumulated leaks can cause memory pressure, degraded performance, failed allocations, service crashes, or full system unavailability. Because exploitation requires local access and targets availability only, this is most relevant as a post-compromise disruption technique or abuse by an untrusted local user/process.

How to fix it

Update to a Linux kernel version or vendor kernel package that includes the Tegra video driver fix ensuring __v4l2_subdev_state_free() is called on all __tegra_channel_try_format() error paths. Because no exact fixed versions were provided in the input, use the patched kernel release from the relevant Linux distribution, hardware vendor, BSP, or long-term-stable kernel branch. For embedded or appliance deployments, obtain the updated board support package or backport the upstream kernel patch that adds centralized cleanup for sd_state in __tegra_channel_try_format(). If immediate patching is not possible, reduce exposure by disabling or unloading the Tegra video driver where not required, restricting access to /dev/video* and /dev/media* device nodes to trusted users only, applying device cgroup controls for containers, and preventing untrusted local workloads from accessing host media devices.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or source tree contains the fix for the Tegra video driver memory leak in __tegra_channel_try_format(). Source validation can be performed by checking that error paths after v4l2_subdev_call() failures jump to a cleanup path that calls __v4l2_subdev_state_free(sd_state) before returning. Runtime exposure can be checked by confirming whether Tegra media/video drivers are loaded and whether /dev/video* or /dev/media* nodes are accessible to untrusted users or containers. After patching, run vendor or kernel regression tests for V4L2 try-format operations and monitor for absence of repeatable memory growth, slab growth, out-of-memory events, or kernel instability when exercising the media interface.

Typical attack path

1. Obtain local code execution or an interactive local account on an affected Linux system.
2. Confirm that the system uses an affected kernel and has Tegra video/media functionality exposed through V4L2/media device nodes.
3. Open the relevant /dev/video* or /dev/media* device interface.
4. Repeatedly issue format-negotiation or try-format operations that exercise the Tegra video driver path.
5. Trigger v4l2_subdev_call() failure conditions that return through the vulnerable error paths in __tegra_channel_try_format().
6. Continue the loop to leak kernel memory and create sustained memory pressure.
7. Cause service degradation, application failures, out-of-memory events, or system instability/reboot.

How to detect it

Detection should focus on local abuse patterns and resulting system instability rather than network indicators, because this is a local kernel memory leak in a media driver. Review kernel logs, system journal, audit logs, and endpoint telemetry for repeated access to V4L2/media device nodes by unusual users, services, scripts, or containers. Look for bursts of ioctl activity against /dev/video* or /dev/media*, recurring media/Tegra driver errors, increasing kernel memory or slab usage, out-of-memory killer activity, allocation failures, hung tasks, unexpected service restarts, or reboots following media-device operations. On Linux systems, useful sources include journalctl/kern.log/dmesg, auditd records for device-node access, eBPF/EDR syscall telemetry for repeated ioctl calls, container runtime device-mount logs, and memory/OOM monitoring. If named threat intelligence is unavailable, treat suspicious local repeated device access plus memory exhaustion on Tegra systems as the strongest exploitation signal.

• __tegra_channel_try_format
• __v4l2_subdev_state_alloc
• __v4l2_subdev_state_free
• v4l2_subdev_call
• tegra-video
• /dev/video
• /dev/media
• Out of memory
• oom-killer
• invoked oom-killer
• page allocation failure
• Memory allocation failure
• hung task
• V4L2
• tegra_channel

What your security team should do

• Prioritize patching systems that use NVIDIA Tegra platforms, embedded camera/video workloads, robotics, edge devices, or appliance images where local denial of service would affect operations.
• Inventory Linux systems for Tegra video/media driver usage and exposed V4L2/media device nodes before applying broad emergency response; non-Tegra systems are unlikely to be practically affected by this specific driver flaw.
• Apply the relevant vendor, distribution, BSP, or long-term-stable kernel update that contains the fix; where necessary, backport the small memory-management patch into maintained custom kernels.
• Restrict access to /dev/video* and /dev/media* devices to trusted users and services only, especially on multi-user systems and container hosts.
• Review container, sandbox, and workload policies to ensure untrusted workloads are not granted host video/media device access unless required.
• Monitor affected systems for memory pressure, kernel out-of-memory activity, abnormal restarts, or repeated media-device errors that could indicate attempted abuse.
• Treat exploitation likelihood as currently low because EPSS is stable at 0.00128, the issue is not in CISA KEV, and no public exploit maturity is reported, but remediate during normal kernel maintenance due to potential availability impact.