CVE-2024-27074

What it actually does

Memory leak in go7007_load_encoder where boot_fw bounce buffer is allocated but never freed before the containing go7007 struct is kfree'd during saa7134_go7007_init teardown.

Why it matters to the business

Repeated initialization of affected video capture hardware on long-running Linux systems gradually depletes kernel memory, eventually causing performance degradation, OOM kills, or system instability; high ecosystem prevalence in the Linux kernel increases exposure for servers and embedded devices using the saa7134 or go7007 drivers.

How an attack unfolds

An attacker with local access triggers repeated calls to saa7134_go7007_init (and thus go7007_boot_encoder o go7007_load_encoder) via device probing or module reload paths; each cycle leaks the boot_fw allocation, exhausting memory without requiring special privileges beyond loading the driver.

How to fix it

Update the Linux kernel to the commit fixing the leak (7f11dd3d165b178e738fe73dfeea513e383bedb5) or apply the equivalent stable backport; rebuild and reboot with the patched kernel; unload or blacklist the go7007/saa7134 modules if the hardware is not required.

How to confirm the fix worked

Confirm the running kernel contains commit 7f11dd3d165b178e738fe73dfeea513e383bedb5 or later equivalent; use kmemleak or /sys/kernel/debug/kmemleak to scan for unreferenced boot_fw allocations after exercising the driver init path; verify no new leaks appear after repeated saa7134_go7007_init invocations.

Typical attack path

1. Obtain local user or unprivileged access on a Linux system with the vulnerable saa7134/go7007 driver present
2. Trigger repeated device initialization or module load/unload sequences that invoke go7007_load_encoder
3. Accumulate leaked kernel memory allocations until system resources are exhausted
4. Induce denial of service via OOM conditions or force kernel panic on memory pressure

How to detect it

Review kernel logs for repeated go7007 or saa7134 initialization messages; inspect kmemleak reports or slabinfo for growing boot_fw allocations; correlate with process activity that triggers media device probing; no public exploit artifacts are known.

What your security team should do

• Prioritize kernel upgrade to the fixed commit on all systems exposing the saa7134 or go7007 drivers
• Audit for presence of the vulnerable driver modules and disable them where video capture hardware is unused
• Enable kernel memory leak detectors in staging or test environments to catch similar issues early
• Monitor EPSS and KEV updates for any future elevation in exploitability