CVE-2024-42301

What it actually does

Local buffer overflow in the Linux kernel parport driver caused by unbounded sprintf in do_hardware_base_addr, resulting in stack corruption and kernel panic when the destination buffer is exceeded.

Why it matters to the business

System crashes, denial of service, or potential local privilege escalation on Linux systems using the parport module; affects organizations running vulnerable kernels with 40 downstream dependents amplifying exposure across ecosystems.

How an attack unfolds

An attacker with local user access crafts input that triggers the vulnerable sprintf call in the parport hardware address handling path, overflowing the stack buffer and bypassing stack canaries to cause corruption or attempt code execution; documented in zero-day campaigns by espionage and financially motivated actors targeting Linux kernel flaws.

How to fix it

Upgrade the Linux kernel to a version containing commit 166a0bddcc27de41fe13f861c8348e8e53e988c8 or later; rebuild and reboot with the patched parport module; apply vendor backports for stable trees where available.

How to confirm the fix worked

Verify the running kernel contains the referenced commit via git log or kernel version string; inspect parport source for snprintf usage in place of sprintf; attempt reproduction of the original stack trace under controlled conditions to confirm absence of the flaw.

Typical attack path

1. Obtain local shell or process execution on target Linux system
2. Trigger parport device initialization or hardware base address query via user-space application
3. Supply oversized input to exercise the sprintf path in do_hardware_base_addr
4. Overwrite adjacent stack frames leading to __stack_chk_fail or kernel panic
5. Escalate via corrupted kernel state or chain with other primitives for code execution

How to detect it

Search kernel logs for stack-protector panics referencing do_hardware_base_addr and parport; review audit logs for unusual parport device access by non-root processes; correlate with process execution of applications interacting with /dev/parport.

• Kernel panic: stack-protector: Kernel stack is corrupted in: do_hardware_base_addr
• parport module tainted stack trace containing QThread or EFileApp
• Call trace ending in __stack_chk_fail+0x2c/0x38

What your security team should do

• Prioritize kernel updates on all systems exposing parport functionality within the next patching cycle
• Restrict unprivileged local access to parport devices via device permissions and SELinux/AppArmor policies
• Monitor EPSS and threat actor reports for any increase in in-the-wild exploitation
• Test patched kernels in staging environments before broad deployment