CVE-2022-42895/6 _ Linux Kernel Infoleak & UAF in Bluetooth L2CAP
🦷

CVE-2022-42895/6 _ Linux Kernel Infoleak & UAF in Bluetooth L2CAP

⚠️ [ ORIGIN SOURCE ]
https://github.com/google/security-research/security/advisories/GHSA-vccx-8h74-2357
📅 [ Archival Date ]
Nov 30, 2022 6:55 PM
🏷️ [ Tags ]
LINUX
✍️ [ Author ]

Tamás Koczka, Andy Nguyen

💣 [ PoC / Exploit ]
https://crash.link/cve-2022-42895-6
image

CVE-2022-42895 Kernel (Linux) > v3.0.0

Summary

There is an infoleak vulnerability in the Linux kernel's net/bluetooth/l2cap_core.c's l2cap_parse_conf_req function which can be used to leak kernel pointers remotely.

The bug was introduced in commit 42dceae (version: 3.0.0, date: 2011-Oct-17).

Severity

Moderate - The leak in Bluetooth L2CAP handling can be used to leak kernel pointers remotely.

Proof of Concept

The bug can be triggered remotely on a KASAN-enabled kernel with the PoC below. Tested on Ubuntu 22.04, precondition: HighSpeed support needs to be enabled via e.g. btmgmt hs on

Further Analysis

Commit 42dceae added parsing Extended Flow Specification option in L2CAP Config Request, which uses a local struct l2cap_conf_efs efs on the stack which is normally initialized with data sent remotely (and remote_efs is set to 1). This structure is also written back to the remote client (as a confirmation of successful configuration change).

The problem is this code path checks the FLAG_EFS_ENABLE channel flag instead of the remote_efs variable to decide if the l2cap_conf_efs efs struct should be used or not and it is possible to set the FLAG_EFS_ENABLE flag without actually sending EFS configuration data and in this case the uninitialized l2cap_conf_efs efs struct will be sent back to the remote client thus leaking information about kernel memory contents, including kernel pointers.

The FLAG_EFS_ENABLE flag can also be set on the channel at other places by satisfying the requirements of __l2cap_efs_supported:

  1. L2CAP_FC_A2MP local channel availability: this requires HCI_HS_ENABLED to be enabled which can be achieved via the BT management interface, by e.g. calling btmgmt hs on (it is off by default on the systems used for testing)
  2. L2CAP_FEAT_EXT_FLOW feature mask: which can be turned on via the L2CAP_INFO_RSP command.

To actually set the FLAG_EFS_ENABLE flag l2cap_build_conf_req needs to be called, which can be done e.g. via the L2CAP_CONN_RSP command.

Sample Packet of Leaked Information

02 00 21 2F 00 2B 00 01 00 05 01 27 00 03 00 00
00 00 00 01 02 A0 02 04 09 03 00 00 D0 07 E0 2E
00 00 06 10 21 ED BF 8E FF FF FF FF 80 00 E3 8D
FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00

The following pointers were confirmed to be valid addresses from the kernel space:

21 ED BF 8E FF FF FF FF = 0xffffffff8ebfed21
80 00 E3 8D FF FF FF FF = 0xffffffff8de30080

Reachability

The affected code path is reached via A2MP which depends on the CONFIG_BT_HS (Bluetooth High Speed) kernel config which is disabled by default, but it is enabled on some well-known distributions (including Ubuntu).

Also HCI_HS_ENABLED needs to be true, which can be turned on via the management interface, but we are not aware of any configuration currently where it is turned on by default.

Patch

The vulnerability was fixed by also checking if remote_efs is true in commit b1a2cd5.

Timeline

Date reported: 10/06/2022

Date fixed: 10/26/2022

Date disclosed: 11/28/2022

image

CVE-2022-42896 Kernel (Linux) > v3.16.0

Summary

There are use-after-free vulnerabilities in the Linux kernel's net/bluetooth/l2cap_core.c's l2cap_connect and l2cap_le_connect_req functions which may allow code execution and leaking kernel memory (respectively) remotely via Bluetooth.

The l2cap_le_connect_req bug was introduced in commit 27e2d4c (version: 3.12.0, date: 2013-Dec-05), the SMP channel is available since commit 70db83c (version: 3.16.0, date: 2014-Aug-14).

Severity

Moderate

Proof of Concept

UAF read in l2cap_le_connect_req

UAF write in l2cap_connect

To make SMP available for BR/EDR devices (in case of a hardware supporting it is not available), you can force it by running: echo Y > /sys/kernel/debug/bluetooth/hci0/force_bredr_smp

Further Analysis

Bug Analysis There are UAF races in l2cap_connect and l2cap_le_connect_req methods. After a channel is created via the new_connection callback, it is not locked but __set_chan_timer sets up a timer which can call l2cap_chan_timeout and can cleanup the channel before the method finishes, causing UAF read in l2cap_le_connect_req and UAF write in l2cap_connect.

As the channel timeout is normally 40 seconds (L2CAP_CONN_TIMEOUT), winning the race would be infeasible, but due to a bug in SMP's implementation, SMP channels created by smp_new_conn_cb have their get_sndtimeo callback set to l2cap_chan_no_get_sndtimeo which returns 0 as timeout value thus causing the timer to run immediately (on a different thread) after the __set_chan_timer call.

Note: in l2cap_le_connect_req (without FLAG_DEFER_SETUP), the timer is canceled via the l2cap_chan_ready call almost immediately after the __set_chan_timer call, but even this small time window enough for the timer with 0 timeout to start.

Another root cause of the issue can be that the SMP channel is available via l2cap_global_chan_by_psm if the request contains psm=0. Multiple channels can be registered without PSM (PSM is 0, and channel is identified by SCID) but only one of them is returned (which needs to be SMP to be able to trigger the vulnerability).

Similar issue within l2cap_connect:

The affected code path in SMP implementation:

static inline struct l2cap_chan *smp_new_conn_cb(struct l2cap_chan *pchan)
{
    …
    chan->ops = &smp_chan_ops;
    …
}

static const struct l2cap_ops smp_chan_ops = {
    …
    .get_sndtimeo = l2cap_chan_no_get_sndtimeo,
    …
};

static inline long l2cap_chan_no_get_sndtimeo(struct l2cap_chan *chan)
{
    return 0;
}

Reachability SMP channel is available for Bluetooth Low Energy since BT 4.0 (~2009) which can be used to trigger the UAF read in l2cap_le_connect_req, and it is also available for BT BR/EDR since BT 5.2 (~2020, to support Secure Connections) to trigger the UAF write in l2cap_connect.

No other prerequisites were found, the bugs were triggered on a KASAN-enabled Ubuntu 22.04 kernel (an artificial delay was added before the UAF read/write to make winning the race easier).

Note: it is possible that the bugs can be triggered via other channels which may be created automatically by the specific environment.

Patch

The vulnerability was fixed by not accepting 0 as a valid PSM value in commit 711f8c3 and by preventing l2cap_global_chan_by_psm to give back L2CAP_CHAN_FIXED channels in commit f937b75.

Timeline

Date reported: 10/06/2022

Date fixed: 10/26/2022

Date disclosed: 11/28/2022