CVE-2024-42301: Linux Kernel Buffer Overflow Vulnerability

CVE-2024-42301 Overview

CVE-2024-42301 is an out-of-bounds write vulnerability in the Linux kernel's parport (parallel port) driver subsystem. The vulnerability exists in the do_hardware_base_addr function where the use of sprintf for string formatting operations can lead to buffer overflow conditions. When exploited, this vulnerability can corrupt the kernel stack, potentially leading to kernel panic, denial of service, or local privilege escalation.

Critical Impact

This vulnerability allows a local attacker with low privileges to potentially achieve high impact on confidentiality, integrity, and availability through kernel stack corruption, as evidenced by kernel panic events observed in production environments.

Affected Products

• Linux Kernel (multiple versions)
• Debian Linux distributions (covered by LTS announcements)
• HUAWEI HUAWEI QingYun PGUX-W515x-B081 systems (as noted in kernel panic traces)

Discovery Timeline

• August 17, 2024 - CVE-2024-42301 published to NVD
• November 3, 2025 - Last updated in NVD database

Technical Details for CVE-2024-42301

Vulnerability Analysis

This vulnerability stems from unsafe string formatting practices in the Linux kernel's parallel port driver. The sprintf function does not perform bounds checking when writing formatted data to a destination buffer. In the do_hardware_base_addr function within the parport module, this leads to an out-of-bounds write condition when the formatted string exceeds the allocated buffer size.

The kernel stack trace from an actual incident demonstrates the severity of this issue, showing a stack-protector triggered kernel panic in the do_hardware_base_addr+0xcc/0xd0 function within the parport module. The stack-protector mechanism detected kernel stack corruption, indicating that the buffer overflow had overwritten the stack canary value.

Root Cause

The root cause is the use of the unsafe sprintf function instead of the bounds-checked snprintf variant. The sprintf function writes formatted output to a buffer without any length limitation, allowing data to be written beyond the buffer's allocated boundaries. When processing hardware base address information in the parport driver, if the formatted string is longer than expected, it will overflow the destination buffer and corrupt adjacent memory on the stack.

The fix involves replacing sprintf calls with snprintf, which accepts a maximum buffer size parameter, ensuring that writes are truncated rather than overflowing the buffer boundary.

Attack Vector

The attack vector is local, requiring the attacker to have local access to the system with low-level privileges. Exploitation involves triggering the vulnerable code path in the parport driver, potentially by:

1. Loading the parport kernel module with specially crafted parameters
2. Interacting with parallel port device nodes that trigger the do_hardware_base_addr function
3. Manipulating hardware configuration through sysfs or ioctl calls to cause oversized string formatting

The stack trace captured during exploitation shows the call chain:

• dump_backtrace → show_stack → dump_stack → panic → __stack_chk_fail → do_hardware_base_addr

The __stack_chk_fail call indicates the stack canary was corrupted, demonstrating successful buffer overflow exploitation. On systems without stack protection, an attacker could potentially achieve arbitrary code execution in kernel context.

Detection Methods for CVE-2024-42301

Indicators of Compromise

• Kernel panic messages containing "stack-protector: Kernel stack is corrupted in: do_hardware_base_addr" in system logs
• Unexpected crashes or system instability when interacting with parallel port hardware or the parport module
• Kernel log entries showing __stack_chk_fail calls originating from the parport module
• Anomalous loading patterns of the parport kernel module

Detection Strategies

• Monitor kernel logs (dmesg, /var/log/kern.log) for stack-protector failures mentioning parport or do_hardware_base_addr
• Implement runtime integrity monitoring for kernel modules, specifically watching for unusual parport module behavior
• Deploy endpoint detection solutions capable of identifying kernel-level memory corruption attempts
• Enable kernel auditing to track module loading and unloading events for the parport driver

Monitoring Recommendations

• Configure log aggregation to alert on kernel panic events with stack corruption signatures
• Monitor for repeated attempts to load or interact with the parport module from non-standard processes
• Track file access patterns to /dev/parport* device nodes for unusual activity
• Implement system call auditing for ioctl operations targeting parallel port devices

How to Mitigate CVE-2024-42301

Immediate Actions Required

• Apply the latest kernel patches from the Linux kernel stable tree that address this vulnerability
• If parallel port functionality is not required, disable or blacklist the parport kernel module
• Restrict access to parallel port device nodes using appropriate file permissions
• Monitor systems for signs of exploitation attempts while patches are being deployed

Patch Information

The Linux kernel development team has released patches across multiple stable kernel branches. The fix replaces unsafe sprintf calls with bounds-checked snprintf to prevent buffer overflows. Patches are available through the following kernel git commits:

• Kernel Git Commit 166a0bd
• Kernel Git Commit 47b3dce
• Kernel Git Commit 7789a1d
• Kernel Git Commit 7f4da75
• Kernel Git Commit a44f88f
• Kernel Git Commit ab11dac
• Kernel Git Commit b579ea3
• Kernel Git Commit c719b39

Debian users should refer to the Debian LTS Announcement for October 2024 and Debian LTS Announcement for January 2025 for distribution-specific patching guidance.

Workarounds

• Blacklist the parport module by adding blacklist parport to /etc/modprobe.d/blacklist.conf if parallel port functionality is not needed
• Restrict access to parport-related device files using chmod/chown to limit exposure to trusted users only
• Enable kernel stack protection mechanisms (stack canaries) if not already enabled to detect exploitation attempts
• Consider using mandatory access control (SELinux/AppArmor) policies to restrict parport module interactions

# Disable parport module if not required
echo "blacklist parport" >> /etc/modprobe.d/blacklist-parport.conf
echo "blacklist parport_pc" >> /etc/modprobe.d/blacklist-parport.conf

# Remove currently loaded parport modules
rmmod parport_pc 2>/dev/null
rmmod parport 2>/dev/null

# Verify module is blacklisted
cat /etc/modprobe.d/blacklist-parport.conf