Sungwoo Kim

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.61 Description: A null pointer dereference issue has been identified in the Linux kernel's Bluetooth functionality, specifically in the `hci read supported codecs` function. This issue arises when the ` hci cmd sync sk()` function returns NULL for unknown opcodes, leading to a null pointer dereference in the `cmd sync` function for `HCI OP READ LOCAL CODECS`. The problem occurs because there is no `hci cc` entry for `HCI OP READ LOCAL CODECS`, causing the function to assume a status value of `skb->data[0]`. This results in a null pointer dereference in the range `[0x0000000000000070-0x0000000000000077]`. Recommendations: To resolve this issue, update the Linux kernel to version 6.6.61 or later. As a temporary workaround, consider disabling the Bluetooth functionality until a patch is available.

An issue exists in the Bluetooth L2CAP implementation within the `net/bluetooth/l2cap core.c` module. The `l2cap le flowctl init()` function fails to properly validate input data, specifically when the `le mtu` variable in `hdev` does not fall within a valid range. This lack of validation can lead to a division-by-zero error or an integer overflow, which may allow a remote attacker to cause a denial of service.

The issue is related to a slab-use-after-free vulnerability in the `msft do close()` function. This vulnerability is caused by a race condition where the `msft->data` is freed in `hci release dev()` but still used in `msft do close()`. The vulnerability can be exploited to impact the confidentiality, integrity, and availability of protected information. Technical details about exploitation include the use of the `mutex lock()` function on a freed `msft->filter lock` and the `kfree()` function to free the `msft` data.

The issue is related to a slab-use-after-free vulnerability in the `l2cap connect()` function. This vulnerability can be exploited due to a race condition, allowing an attacker to potentially impact the confidentiality, integrity, and availability of protected information. The vulnerability occurs when the `chan` variable is freed early, and then its memory is accessed again, leading to a use-after-free condition. The `l2cap connect()` function is used in the Bluetooth L2CAP protocol implementation. Technical details about exploitation include: - The `l2cap bredr sig cmd` function calls `l2cap connect()`, which allocates memory for the `chan` variable. - The `l2cap conn del` function frees the `chan` variable, but due to the race condition, the memory can be accessed after it has been freed. - The vulnerability can be triggered by exploiting the race condition between the allocation and deallocation of the `chan` variable.

The issue is related to the `l2cap sock release` function in the Linux kernel, specifically in the `net/bluetooth/l2cap sock.c` file. It involves a use-after-free error because the children of an `sk` are mishandled. This could potentially allow an attacker to cause a denial of service or have other impacts.

The issue is related to a Bluetooth vulnerability in the Linux kernel, specifically an overflow in the L2CAP protocol. By continuously sending L2CAP CONF REQ packets, an attacker can cause the `chan->num conf rsp` variable to increase multiple times, eventually wrapping around the maximum number, which is 255. This is prevented by adding a boundary check with `L2CAP MAX CONF RSP`. The vulnerability can be exploited by sending packets with invalid sizes.

The issue is related to an integer wraparound in the `l2cap config req` function in `net/bluetooth/l2cap core.c`, which can be exploited via `L2CAP CONF REQ` packets. This may allow an attacker to execute arbitrary code.