CVE-2024-27075

What it actually does

Excessive stack frame allocation (3624 bytes) in stv0367ter_set_frontend due to duplicated i2c_msg structures under KASAN_STACK, exceeding clang's 2048-byte limit and risking stack overflow.

Why it matters to the business

Kernel compilation with clang fails or warns on DVB-enabled builds, delaying secure kernel updates for distributions and embedded devices using affected tuners; low real-world urgency given age and zero KEV status.

How an attack unfolds

An attacker would need local code execution to invoke stv0367ter_set_frontend repeatedly while KASAN_STACK instrumentation is active, causing stack exhaustion; no public exploits or threat actor campaigns observed despite generic kernel actor references.

How to fix it

Upgrade torvalds/linux GIT to commit b562e44f507e863c6792946e4e1b1449fbbac85d or later; rebuild kernel with the reworked stv0367_writereg and noinline_for_stack annotations applied.

How to confirm the fix worked

Recompile the stv0367 driver with clang and KASAN_STACK enabled; confirm stv0367ter_set_frontend stack frame size no longer exceeds 2048 bytes and build succeeds without -Wframe-larger-than errors.

Typical attack path

1. Obtain local execution context on affected Linux kernel
2. Trigger DVB frontend initialization via stv0367 driver
3. Force repeated register writes that duplicate stack frames under instrumentation
4. Exhaust kernel stack leading to crash or controlled memory corruption

How to detect it

Search kernel build logs for 'stack frame size exceeds limit' warnings referencing stv0367.c; no runtime IOCs expected as this is a compile-time stack usage issue.

What your security team should do

• Apply the referenced commit immediately on any custom kernels using stv0367
• Audit kernel build pipelines for clang + KASAN configurations
• Monitor upstream stable branches for backports of b562e44f507e
• Disable KASAN_STACK in non-debug builds if compilation issues persist