CVE-2022-3078

What it actually does

Missing validation of vzalloc return value combined with missing kfree on allocated buffers in the vidtv_s302m driver allows kernel memory to be leaked or left in an inconsistent state, resulting in local denial of service.

Why it matters to the business

Systems running affected kernels may experience unexpected crashes or resource exhaustion when the test video driver is exercised, requiring kernel updates or reboots that interrupt workloads and increase maintenance overhead.

How an attack unfolds

An attacker with local access loads or triggers the vidtv test driver, causes the allocation path in vidtv_s302m.c to be executed without proper error checking or cleanup, and either exhausts memory or triggers a subsequent kernel fault.

How to fix it

Upgrade the Linux kernel to a version containing commit 4b0986a3613c92f4ec1bdc7f60ec66fea135991f or later; rebuild and reboot with the patched kernel. Disable or remove the vidtv test driver if it is not required.

How to confirm the fix worked

Confirm the running kernel contains commit 4b0986a3613c92f4ec1bdc7f60ec66fea135991f, verify that vzalloc result checks and corresponding kfree calls exist in drivers/media/test-drivers/vidtv/vidtv_s302m.c, and test that module load/unload cycles no longer leak memory under repeated allocation paths.

Typical attack path

1. Obtain local user or container access on a Linux system
2. Load or exercise the vidtv test media driver module
3. Invoke the allocation routine in vidtv_s302m.c that omits vzalloc result check and kfree
4. Trigger repeated allocation or subsequent kernel operations that rely on the leaked or dangling memory
5. Observe kernel panic, OOM killer activity, or system hang

How to detect it

Review kernel logs for OOM killer invocations or slab allocation warnings referencing vidtv_s302m, inspect module load history for vidtv, and search process or audit logs for local users repeatedly exercising media test interfaces.

• vidtv_s302m
• vzalloc.*vidtv
• drivers/media/test-drivers/vidtv/vidtv_s302m.c

What your security team should do

• Prioritize kernel upgrade to the fixed commit on all systems exposing the vidtv driver
• Audit kernel configurations to ensure test drivers are not enabled in production builds
• Monitor for local privilege-escalation attempts that could chain this issue with other kernel flaws