UBUNTU-CVE-2026-90087: Medium severity ubuntu/linux-hwe-edge vulnerability

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: do not leak an hciconn when a second LE connect is rejected createleconncomplete() decides whether the failed connection is still pending by comparing it against hcilookupleconnect(), which returns the first LE connection in BTCONNECT. That is the same connection only while at most one is pending. Two can be pending. Connections created on the passive scan path sit in BTCONNECT with HCICONNSCANNING set and are invisible to hcilookupleconnect() until hcilecreateconnsync() clears the flag when their command is issued, so the -EBUSY guard in hciconnectle() does not prevent a second connection from being queued while the first is still on the scan path. Whenever two connections are in BTCONNECT at once, the lookup may return one connection while createleconncomplete() is reporting the failure of the other; the early exit then drops the error and hciconnfailed() never runs on the connection that failed. The controller also rejects a second HCIOPLECREATECONN issued while another connection creation is still outstanding, per Core Spec Vol 4, Part E. The spec calls for Command Disallowed there; the bcm43438 observed here answers with an LMP/LL error code instead, which bttoerrno() maps to the -EPROTO (-71) in the log below. The leaked connection stays in BTCONNECT forever, and because hciconnectle() refuses to dial while hcilookupleconnect() finds anything, every subsequent attempt to reach any peer fails with -EBUSY and no command reaches the controller at all. Seen on a bcm43438 with two BLE peers polled on the same interval (state 5 is BTCONNECT; both handles are UNSET ones, allocated from the ida above HCICONNHANDLEMAX): Bluetooth: hci1: Opcode 0x2013 failed: -71 # hcitool con < LE 14:9C:EF:03:68:81 handle 3840 state 5 lm CENTRAL < LE C4:D3:6A:8C:B5:38 handle 3841 state 5 lm CENTRAL A btmon capture across the next ten minutes of connect attempts contains no HCIOPLECREATECONN at all; outgoing LE connections do not recover until the adapter is reset. With this change the same scenario fails the rejected connection cleanly and further connects to both peers go through. Ask about the connection itself instead of about the device.