CVE-2024-50227 in Linux
Summary
by MITRE • 11/09/2024
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan()
KASAN reported following issue:
BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt]
Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER
Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt]
Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt]
tb_scan_port+0xa6f/0x2060 [thunderbolt]
tb_handle_hotplug+0x17b1/0x3080 [thunderbolt]
process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30
This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack.
Fix this by assigning to max directly in the loop body.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2025
The vulnerability identified as CVE-2024-50227 represents a critical stack-based out-of-bounds read condition within the Linux kernel's thunderbolt subsystem. This issue manifests specifically in the tb_retimer_scan function where a stack buffer overflow occurs due to improper loop boundary handling. The vulnerability is classified under CWE-129 as an "Improper Validation of Array Index" and represents a classic example of an out-of-bounds memory access that could potentially lead to system instability or information disclosure. The kernel's KASAN (Kernel Address Sanitizer) detection mechanism identified this flaw during runtime execution when the kworker process attempted to access memory beyond the allocated stack buffer boundaries.
The technical flaw occurs within the tb_retimer_scan function where a loop variable increments beyond its intended boundary, causing the code to read past the end of a stack-allocated array. The stack trace reveals that the issue originates from the thunderbolt subsystem's hotplug handling mechanism, specifically within the workqueue execution context where kworker/u56:0 processes thunderbolt device events. The loop variable max is incremented incorrectly, causing it to reach a value of 3 instead of the expected 2, which results in the second loop iteration accessing memory that extends beyond the declared array bounds. This memory access pattern violates the fundamental principle of array boundary validation and creates a potential attack surface where malicious actors could exploit the out-of-bounds read to extract kernel memory contents or potentially cause system crashes.
The operational impact of this vulnerability extends beyond simple system instability as it affects the core thunderbolt device management functionality within the Linux kernel. When triggered, this flaw could cause kernel panics, system hangs, or unpredictable behavior during thunderbolt device enumeration and hotplug events. The vulnerability is particularly concerning in environments where thunderbolt devices are frequently connected and disconnected, as the likelihood of triggering this condition increases proportionally with device activity. From an ATT&CK perspective, this vulnerability could be leveraged as part of a broader attack chain targeting kernel memory corruption, potentially enabling privilege escalation or information gathering attacks that could compromise the integrity of the entire system.
Mitigation strategies for this vulnerability should focus on immediate patch application as provided by the kernel maintainers, which involves correcting the loop variable assignment to properly handle array bounds. The fix requires modifying the tb_retimer_scan function to assign the max value directly within the loop body rather than allowing the loop variable to increment beyond the valid array boundaries. System administrators should prioritize updating their kernel versions to include this fix, particularly in production environments where thunderbolt devices are actively used. Additionally, monitoring systems should be enhanced to detect potential KASAN reports or kernel oops messages that might indicate exploitation attempts. Organizations should also consider implementing runtime protections such as kernel lockdown modes and ensuring proper device access controls to minimize the attack surface. The vulnerability demonstrates the importance of rigorous code review processes for kernel subsystems and highlights the critical need for automated testing tools like KASAN to detect such memory safety issues before they can be exploited in real-world scenarios.