In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect() Extend a critical section to prevent chan from early freeing. Also make the l2cap_connect() return type void. Nothing is using the returned value but it is ugly to return a potentially freed pointer. Making it void will help with backports because earlier kernels did use the return value. Now the compile will break for kernels where this patch is not a complete fix. Call stack summary: [use] l2cap_bredr_sig_cmd l2cap_connect + mutex_lock(&conn->chan_lock); ¦ chan = pchan->ops->new_connection(pchan); <- alloc chan ¦ __l2cap_chan_add(conn, chan); ¦ l2cap_chan_hold(chan); ¦ list_add(&chan->list, &conn->chan_l); ... (1) + mutex_unlock(&conn->chan_lock); chan->conf_state ... (4) <- use after free [free] l2cap_conn_del + mutex_lock(&conn->chan_lock); ¦ foreach chan in conn->chan_l: ... (2) ¦ l2cap_chan_put(chan); ¦ l2cap_chan_destroy ¦ kfree(chan) ... (3) <- chan freed + mutex_unlock(&conn->chan_lock); ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: slab-use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0 net/bluetooth/l2cap_core.c:4260 Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311
With Rapid7 live dashboards, I have a clear view of all the assets on my network, which ones can be exploited, and what I need to do in order to reduce the risk in my environment in real-time. No other tool gives us that kind of value and insight.
– Scott Cheney, Manager of Information Security, Sierra View Medical Center