CVE-2026-53382

What it actually does

This flaw is a NULL pointer dereference in the Linux kernel vidtv media test driver. Under an allocation-failure condition during PID context initialization for PMT section PIDs, the driver can incorrectly continue as if initialization succeeded. A later vidtv_mux_push_si() call may dereference a NULL PID context while updating the continuity counter, causing a kernel general protection fault or oops. The practical technical impact is local denial of service through a kernel crash or system instability on systems where the vulnerable vidtv driver is present and reachable.

Why it matters to the business

Successful exploitation can crash or destabilize affected Linux systems, causing service interruption, failed workloads, or unplanned reboots. Because this issue is in a media test driver rather than a broadly exposed network service, broad internet-scale exploitation is unlikely, and the reported EPSS score is low. However, systems using the vidtv driver, test environments, CI kernels, media development hosts, or platforms that allow untrusted users to load or interact with this module may face operational disruption.

How an attack unfolds

An attacker first needs local ability to interact with the vulnerable kernel driver or influence conditions under which the vidtv module is initialized and exercised. The vulnerable path occurs when vidtv_mux_pid_ctx_init() fails to create a PID context for PMT section PIDs but does not return an error. When the mux workqueue later runs vidtv_mux_tick(), vidtv_mux_push_si() retrieves the missing PID context and dereferences it without a NULL check. This produces a near-NULL memory access inside vidtv_psi_ts_psi_write_into(), triggering a kernel general protection fault. The result is denial of service, typically visible as a kernel oops, panic depending on kernel settings, or system instability.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the vidtv NULL pointer dereference. The fix adds error handling when creating PMT PID contexts in vidtv_mux_pid_ctx_init() and adds defensive NULL checks in vidtv_mux_push_si(). If a fixed kernel package is not yet available, reduce exposure by preventing the vidtv test driver from loading where it is not required, removing it from custom kernel builds, or blacklisting the module. Restrict privileges that allow users to load kernel modules or access media test-driver interfaces. For production systems, disable unused test drivers as a hardening measure.

How to confirm the fix worked

Confirm that the running kernel contains the patched vidtv changes or has been updated to a vendor kernel release that includes the fix. Verify that the vidtv module is not loaded on systems where it is unnecessary using tools such as lsmod or modinfo. If mitigating by blacklist, confirm the module cannot be loaded after reboot. Review kernel logs after validation testing to ensure there are no new oops messages referencing vidtv_mux_push_si, vidtv_mux_tick, or vidtv_psi_ts_psi_write_into. For source-based builds, confirm the code checks the return value of vidtv_mux_create_pid_ctx_once() for PMT PIDs and performs NULL checks on vidtv_mux_get_pid_ctx() results in vidtv_mux_push_si().

Typical attack path

1. Gain local access or execution in a context that can load, configure, or interact with the Linux vidtv media test driver.
2. Trigger or induce a failure path where vidtv_mux_create_pid_ctx_once() does not create the PMT PID context during vidtv_mux_pid_ctx_init().
3. Cause the vidtv mux workqueue to run and generate service information through vidtv_mux_tick().
4. Reach vidtv_mux_push_si(), where vidtv_mux_get_pid_ctx() returns NULL for the missing PID context.
5. Trigger the NULL pointer dereference when the driver accesses the continuity counter, causing a kernel oops, panic, or service disruption.

How to detect it

Look for evidence of kernel crashes or oops events involving the vidtv media test driver. Relevant log sources include journald, /var/log/kern.log, /var/log/messages, dmesg output, crash dump tooling such as kdump, and kernel panic/oops collection systems. Search for stack traces containing vidtv_mux_push_si, vidtv_mux_tick, vidtv_psi_ts_psi_write_into, or vidtv_psi_pmt_write_into. Also review module-load telemetry, audit logs, or EDR telemetry for loading of the vidtv module shortly before a crash. Because this is a denial-of-service bug rather than a code-execution issue, exploitation artifacts are primarily kernel fault logs, crash dumps, module-load events, and system reboot timelines rather than files dropped by an attacker.

• general protection fault, probably for non-canonical address 0xdffffc0000000000
• KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
• vidtv_psi_ts_psi_write_into
• vidtv_mux_push_si
• vidtv_mux_tick
• vidtv_psi_pmt_write_into
• drivers/media/test-drivers/vidtv/vidtv_psi.c
• drivers/media/test-drivers/vidtv/vidtv_mux.c
• Workqueue: events vidtv_mux_tick
• modprobe vidtv
• insmod vidtv.ko
• vidtv.ko

What your security team should do

• Inventory Linux systems and kernel builds where the vidtv media test driver is enabled, built as a module, or loaded.
• Prioritize patching systems that allow local users, containers with elevated device access, CI jobs, fuzzing workloads, or media-development workflows to interact with kernel media test drivers.
• Apply vendor kernel updates as they become available; no CISA KEV listing or ransomware use is currently reported, so prioritize based on local exposure rather than internet exposure.
• Disable or blacklist the vidtv module on production systems where it is not required.
• Restrict kernel module loading to trusted administrators and review access controls for media devices and test-driver interfaces.
• Monitor kernel logs for vidtv-related oops, panic, or general protection fault messages to identify attempted or accidental triggering.