CVE-2024-42141 in Linux
Summary
by MITRE • 07/30/2024
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: Check socket flag instead of hcon
This fixes the following Smatch static checker warning:
net/bluetooth/iso.c:1364 iso_sock_recvmsg() error: we previously assumed 'pi->conn->hcon' could be null (line 1359)
net/bluetooth/iso.c 1347 static int iso_sock_recvmsg(struct socket *sock, struct msghdr *msg, 1348 size_t len, int flags) 1349 {
1350 struct sock *sk = sock->sk; 1351 struct iso_pinfo *pi = iso_pi(sk); 1352 1353 BT_DBG("sk %p", sk); 1354 1355 if (test_and_clear_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags)) {
1356 lock_sock(sk); 1357 switch (sk->sk_state) {
1358 case BT_CONNECT2: 1359 if (pi->conn->hcon && ^^^^^^^^^^^^^^ If ->hcon is NULL
1360 test_bit(HCI_CONN_PA_SYNC, &pi->conn->hcon->flags)) {
1361 iso_conn_big_sync(sk); 1362 sk->sk_state = BT_LISTEN; 1363 } else {
--> 1364 iso_conn_defer_accept(pi->conn->hcon); ^^^^^^^^^^^^^^ then we're toast
1365 sk->sk_state = BT_CONFIG; 1366 } 1367 release_sock(sk); 1368 return 0; 1369 case BT_CONNECTED: 1370 if (test_bit(BT_SK_PA_SYNC,
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/19/2025
The vulnerability identified as CVE-2024-42141 resides within the Linux kernel's Bluetooth implementation, specifically in the ISO (Individual Stream Option) socket handling code. This issue manifests as a potential null pointer dereference that occurs during the processing of Bluetooth ISO socket receive messages. The flaw stems from an incorrect assumption in the code where the system checks for the existence of a connection handle through the hcon field without proper validation, creating a scenario where a null pointer access could occur under certain conditions. The Smatch static analysis tool flagged this warning at line 1364 in the iso_sock_recvmsg function, indicating that the code previously assumed the hcon field could be null but failed to properly validate this assumption before dereferencing it.
The technical flaw occurs in the iso_sock_recvmsg function where the code attempts to access pi->conn->hcon without ensuring that hcon is not null prior to the access. When the code reaches line 1364, it calls iso_conn_defer_accept(pi->conn->hcon) but the preceding conditional check at line 1359 only validates if pi->conn->hcon exists before checking for specific connection flags. This creates a race condition or logic error where the hcon pointer might be null during the defer accept operation, leading to a kernel panic or system crash. The vulnerability is particularly concerning because it operates at the kernel level where such errors can result in complete system compromise. This type of vulnerability aligns with CWE-476 which describes NULL Pointer Dereference, and represents a classic case of improper null pointer validation in kernel space code.
The operational impact of this vulnerability extends beyond simple system instability to potential security implications within Bluetooth communication frameworks. When exploited, the null pointer dereference could cause the Bluetooth subsystem to crash, leading to denial of service for Bluetooth connectivity and potentially allowing malicious actors to disrupt critical communication channels. The vulnerability affects systems running Linux kernels with Bluetooth ISO support, particularly those implementing Bluetooth Low Energy or classic Bluetooth protocols where ISO connections are utilized. Given that Bluetooth is commonly used in automotive systems, IoT devices, and mobile platforms, this vulnerability could be exploited in various attack scenarios where continuous Bluetooth connectivity is required. The ATT&CK framework categorizes this as a system service disruption technique, potentially enabling further exploitation paths through the compromised Bluetooth subsystem.
Mitigation strategies for CVE-2024-42141 should prioritize immediate kernel updates from trusted sources, as the fix has already been implemented in the upstream kernel code. System administrators should deploy patches that correct the validation logic in the iso_sock_recvmsg function to ensure proper null checking before accessing the hcon field. Additionally, monitoring for unusual Bluetooth connection behaviors or system crashes following Bluetooth operations can help detect exploitation attempts. Organizations should also implement network segmentation to limit Bluetooth exposure where possible, and consider disabling Bluetooth functionality on systems where it is not required for operations. The fix implemented addresses the root cause by ensuring that the socket flag validation occurs before any dereference operations, preventing the null pointer scenario that previously led to system instability. This remediation approach aligns with secure coding practices recommended by the CERT/CC and other security standards that emphasize defensive programming and proper null pointer validation in kernel space code.