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.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.6.37 **Description** The issue is related to a div-by-zero and integer overflow vulnerability in the `l2cap le flowctl init()` function. This vulnerability can be caused by an invalid `hdev->le mtu` value. To fix this, the MTU is moved from `hci dev` to `hci conn` to validate it and stop the connection process earlier if it is invalid. Additionally, a missing validation in `read buffer size()` is added to return an error value if the validation fails. The `hci conn add()` function now returns `ERR PTR()` as it can fail due to a `kzalloc` failure or an invalid MTU value. **Recommendations** To resolve the issue, update the Linux kernel to version 6.6.37 or later. As a temporary workaround, consider disabling the `l2cap le flowctl init()` function until a patch is available. Restrict access to the vulnerable module to minimize the risk of exploitation. Avoid using the `hdev->le mtu` parameter in the affected API endpoint until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** 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. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** 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. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.4.10 **Description** 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. **Recommendations** For Linux kernel versions prior to 6.4.10, update to version 6.4.10 or later to resolve the issue. As a temporary workaround, consider restricting access to the `l2cap sock release` function in `net/bluetooth/l2cap sock.c` until a patch is available.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.1.0-rc2 **Description** 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. **Recommendations** To resolve the issue, update the Linux kernel to version 6.1.0-rc2 or later. As a temporary workaround, consider disabling Bluetooth functionality until a patch is available. Restrict access to the L2CAP protocol to minimize the risk of exploitation. Avoid using the `L2CAP CONF REQ` packet type in the affected API endpoint until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.0.10 **Description** 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. **Recommendations** For Linux kernel versions prior to 6.0.10, update to a version 6.0.10 or later to resolve the issue. As a temporary workaround, consider restricting access to the `l2cap config req` function in `net/bluetooth/l2cap core.c` to minimize the risk of exploitation.