In early 2024, a noteworthy issue in the Linux kernel’s Digital Video Broadcasting (DVB) subsystem was identified and patched. The bug, associated with the code that handles communication with certain TV frontend chips, was flagged as CVE-2024-27075. The root of the problem? Stack frame overflows triggered by large temporary structures, notably flagged by the clang compiler and when Kernel Address Sanitizer (KASAN) was enabled.

Background

The kernel's DVB subsystem lets Linux interact with digital TV tuner hardware. In this case, the bug lived in the driver for the stv0367 frontend chip (drivers/media/dvb-frontends/stv0367.c). These drivers rely heavily on I²C (Inter-Integrated Circuit) for low-level register access.

A previous patch had already worked around some KASAN (Kernel Address Sanitizer) issues in this area. However, when compiling with clang or using KASAN_STACK, the compiler flagged a stack frame size error:

drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than]
 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)

What does this mean?

The stv0367ter_set_frontend function created a stack frame so large that it triggered warnings (or outright errors) on stricter compiler setups, particularly when temporary objects were duplicated due to function inlining.

Root Cause

Several functions, especially those writing to hardware registers (stv0367_writereg and related code), created temporary i2c_msg structures on the stack. When aggressively inlined by the compiler, or when KASAN_STACK instrumentation expanded these structures, a *huge* stack frame was created—enough to potentially cause kernel stack overflow.

Is it exploitable remotely?

Unlikely. This bug itself doesn’t allow arbitrary code execution. Instead, it can cause kernel panics, crashes, or unpredictable behavior if the stack overflows and corrupts critical data. These crashes could be triggered locally, perhaps by a malicious or buggy DVB application.

Systems with certain TV tuner hardware using the stv0367 frontend

- Users compiling the kernel (or modules) with clang or KASAN features enabled (such as custom distros, testing/dev setups)
- Scenarios where an attacker can cause the driver to be loaded and exercised, especially on test/dev systems

Inducing a crash or denial-of-service as the kernel stack is exhausted

Still, this isn’t a traditional “security” exploit leading to privilege escalation—just a potential local crash.

The Fix: Noinline for Stack Safety

The maintainers addressed the bug by reworking the register-access functions and explicitly marking sensitive functions with the noinline_for_stack attribute. This stops the compiler from inlining those routines, which previously caused duplicated local variable allocations and a ballooning stack frame.

Add the noinline_for_stack macro to the stv0367_writereg() and stv0367_readreg() functions

Below is a simplified, representative code snippet of this change.

Old Pattern (Prone to Stack Overflow)

static int stv0367_writereg(struct stv0367_state *state, u8 reg, u8 val)
{
    struct i2c_msg msg[1];
    u8 buf[2] = { reg, val };

    msg[].addr  = state->i2c_addr;
    msg[].flags = ;
    msg[].buf   = buf;
    msg[].len   = 2;

    return i2c_transfer(state->i2c, msg, 1) == 1 ?  : -EIO;
}

New Pattern (Stack Overflow Avoided)

// Use macro to prevent inlining and extra stack duplication
noinline_for_stack
static int stv0367_writereg(struct stv0367_state *state, u8 reg, u8 val)
{
    struct i2c_msg msg;
    u8 buf[2] = { reg, val };

    msg.addr  = state->i2c_addr;
    msg.flags = ;
    msg.buf   = buf;
    msg.len   = 2;

    return i2c_transfer(state->i2c, &msg, 1) == 1 ?  : -EIO;
}

A similar pattern was applied to the readreg function.

References and Further Reading

- Fix commit on LKML
- CVE-2024-27075 at NVD
- Linux Kernel Source: stv0367.c
- About noinline_for_stack

Conclusion

CVE-2024-27075 is a great example of how subtle stack overflows can sneak into complex kernel code—even when the code isn’t directly exploitable, it can still create stability and reliability hazards. The fix here was straightforward: make the functions simpler and prevent the compiler from turning a manageable stack allocation into a catastrophic overflow.

Most end-users running stock kernels on standard distributions won’t hit this bug. However, if you’re compiling your own kernel (especially with clang or KASAN), or work in DVB/TV tuner driver land, it’s important to ensure you pick up this fix.

Stay up to date, and happy hacking!

*This writeup is exclusive and crafted for a simple, clear understanding of how a seemingly minor compiler warning matters for Linux kernel robustness and security.*

Timeline

Published on: 05/01/2024 13:15:51 UTC
Last modified on: 05/04/2025 12:55:28 UTC