CVE-2023-53827

Отчет

A race in the L2CAP disconnect request/response handlers could access a channel that is being destroyed, causing a use-after-free and kernel crash. The fix uses l2cap_chan_hold_unless_zero() and proper locking around channel deletion to avoid referencing freed objects. An adjacent attacker over Bluetooth can trigger this during disconnect handling on an active link. Likely only denial-of-service kind of attack possible, but cannot prove this. The complexity of attack is high, because it requires a precise race condition between the local channel teardown (triggered by the kernel) and a crafted L2CAP_DisconnectReq or L2CAP_DisconnectRsp message sent by the remote peer at exactly the same time. The timing window is very narrow — the attacker must send or respond to the disconnect while the kernel is already in the process of releasing the l2cap_chan structure but before the reference count reaches zero. Achieving this reliably would require repeated connect/disconnect cycles or fuzzing at the signaling layer, making stable exploitation unlikely outside of a controlled test setup.