CVE-2026-46058

What it actually does

This is a local race condition in the Linux kernel Amphion VPU media driver involving the V4L2 memory-to-memory framework. A context can be freed by v4l2_m2m_ctx_release() while v4l2_m2m_try_run() is still about to call device_run() with the same context, causing a use-after-free in kernel space. The observed failure mode is a kernel panic from an invalid read, but because the bug is kernel memory corruption, the theoretical impact can include denial of service, information disclosure, or local privilege escalation depending on system configuration and exploitability.

Why it matters to the business

Systems using affected Linux kernels with the Amphion VPU media driver enabled may be vulnerable to a local attack that can crash the host and interrupt workloads. The risk is highest on devices or servers where untrusted or low-privileged users, containers, applications, or media-processing services can access V4L2 video device nodes. This vulnerability is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, local denial-of-service risk remains operationally relevant for shared systems, embedded devices, and media-processing appliances.

How an attack unfolds

An attacker first obtains local code execution or an account on a system running an affected kernel with the Amphion VPU driver available. They then interact with the relevant V4L2 media device interface, typically through /dev/video* or related media device nodes, and trigger concurrent operations that cause the m2m context release path and job scheduling path to race. If the timing is successful, one thread frees the m2m context while another path continues and attempts to use it in device_run(). This produces a kernel use-after-free and can lead to a kernel oops or panic. In practical terms, the most likely outcome is a system crash; more advanced exploitation would require reliable control over the freed memory and kernel heap state, and no such public exploitation is indicated by the supplied data.

How to fix it

Update to a Linux kernel build from the relevant distribution, vendor, or upstream stable branch that includes the Amphion VPU fix. The fix prevents m2m framework job scheduling for this driver by adding a job_ready callback that returns no ready jobs and removing the job_abort callback path that participates in the race. No exact fixed package versions were provided, so use vendor advisories and kernel changelogs to identify the first fixed build for each supported platform. Where immediate patching is not possible, mitigate by disabling or unloading the Amphion VPU driver if it is not required, removing access to affected V4L2/media device nodes from untrusted users and containers, tightening udev permissions for /dev/video* and /dev/media*, and avoiding deployment of untrusted workloads on systems exposing this hardware interface.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version is at or above the vendor-fixed version, not merely that a fixed package is installed. Review vendor kernel changelogs or source patches for the Amphion VPU change that adds a job_ready callback returning 0 and removes the job_abort callback. Check whether the affected driver is enabled or loaded using kernel configuration, module listings, and media device enumeration. Validate that untrusted users cannot access relevant /dev/video* or /dev/media* nodes unless required. After patching, monitor for absence of kernel oops messages referencing v4l2_m2m_try_run, v4l2_m2m_device_run_work, or invalid reads near address 0x538 during media workload testing.

Typical attack path

1. Gain local access to a system running an affected Linux kernel.
2. Confirm that the Amphion VPU media driver is present, loaded, or reachable through exposed V4L2/media device nodes.
3. Open and exercise the affected video/media device interface from a low-privileged process if permissions allow it.
4. Trigger repeated or concurrent encode/decode, queue, cancel, close, or release operations to race v4l2_m2m_try_run() against v4l2_m2m_ctx_release().
5. Cause the m2m context to be freed while the framework is still attempting to invoke device_run() with that context.
6. Induce a kernel use-after-free, resulting most commonly in a kernel oops, panic, reboot, or service outage.

How to detect it

There are no known network indicators for this local kernel vulnerability. To assess whether exploitation or triggering already occurred, review kernel logs, persistent journal entries, crash dumps, and system reboot records for oops or panic traces involving the V4L2 m2m framework and Amphion VPU driver. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd-journald kernel logs, kdump/vmcore artifacts, auditd records for access to /dev/video* and /dev/media*, and EDR telemetry showing local processes repeatedly opening or closing media device nodes before a crash. Look for invalid memory reads at or near 0000000000000538 and stack traces containing v4l2_m2m_try_run or v4l2_m2m_device_run_work. Because a crash may erase volatile evidence, ensure kernel crash dumping and persistent journaling are enabled on high-risk systems.

• Unable to handle kernel read from unreadable memory at virtual address 0000000000000538
• v4l2_m2m_try_run+0x78/0x138
• v4l2_m2m_device_run_work+0x14/0x20
• v4l2_m2m_ctx_release
• v4l2_m2m_cancel_job
• v4l2_m2m_job_finish
• job_abort
• device_run
• amphion
• /dev/video
• /dev/media
• drivers/media/platform/amphion

What your security team should do

• Prioritize patching systems that expose Amphion VPU hardware or V4L2 media devices to non-administrative users, containers, kiosks, appliances, or media-processing workloads.
• Inventory Linux systems with the Amphion VPU driver enabled, loaded, or packaged, and identify which systems expose /dev/video* or /dev/media* device nodes.
• Apply vendor kernel updates that include the Amphion VPU m2m race fix; schedule reboots where required to activate the fixed kernel.
• If patching is delayed, disable or blacklist the Amphion VPU driver where it is not business-critical.
• Restrict device-node permissions so only trusted service accounts can access affected V4L2/media devices.
• Review kernel logs for prior crashes or oops traces matching the vulnerable code path, especially on shared or multi-user systems.
• Treat unexplained kernel panics involving v4l2_m2m_try_run or amphion media workloads as potential security events until normal fault conditions are ruled out.