CVE-2024-50077 in Linux
Summary
by MITRE • 10/29/2024
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: Fix multiple init when debugfs is disabled
If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc.
With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG():
list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------
kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI
CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth]
set_iso_socket_func+0x68/0x1b0 [bluetooth]
kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth]
__sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ...
This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2025
The vulnerability described in CVE-2024-50077 resides within the Linux kernel's Bluetooth implementation, specifically affecting the ISO (Information Streaming Over) subsystem initialization process. This issue manifests when debugfs functionality is disabled through kernel configuration options such as CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL being unset. The flaw represents a classic case of improper state management where the initialization function fails to properly update internal flags, leading to potential duplicate operations that can result in system instability.
The technical root cause involves the iso_init() function which is responsible for setting up Bluetooth ISO socket protocols. When bt_debugfs fails to initialize due to disabled debugfs support, the function returns early without setting the iso_inited flag to true. This creates a problematic state where subsequent calls to iso_init() will execute the full initialization sequence including calls to proto_register() and bt_sock_register() functions. According to CWE-665 improper initialization, this represents a condition where the system fails to properly establish its initial state, leading to undefined behavior.
The operational impact of this vulnerability becomes particularly severe when combined with specific kernel hardening configurations such as CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION. These settings enable additional runtime checks that detect and panic on data corruption conditions. When duplicate proto_register() calls occur, the kernel's list management subsystem triggers a BUG() condition as demonstrated in the crash trace, showing a "list_add double add" error in lib/list_debug.c. This specific error pattern aligns with ATT&CK technique T1490 for data destruction and T1070 for indicator removal, as the kernel's integrity checking mechanisms detect and abort on corrupted data structures.
The exploitation of this vulnerability requires specific kernel configuration parameters to be set in a particular way, making it less likely to affect general systems but still significant for embedded devices or systems with hardened security configurations. The fix implemented addresses the root cause by removing the early return mechanism that was causing the inconsistent state, ensuring that iso_init() always completes its initialization sequence properly regardless of debugfs availability. This aligns with security best practices outlined in the Linux Kernel Security documentation and represents a defensive programming approach to prevent initialization race conditions. The solution effectively eliminates the possibility of duplicate protocol registration while maintaining system stability under all configuration scenarios.