Odebrany

CVE-2026-99009

opublikowano: 23.10.2026, 15:17

modyfikacja: 23.10.2026, 15:17

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

Bluetooth: RFCOMM: podłącz gniazdo sesji bez rfcomm_mutex

Funkcja RFCOMM connect() wywołana podczas uwierzytelniania łącza BR/EDR
sprawia, że raport blokady jest zależnością cykliczną, a raportowany cykl to a
prawdziwe AB/BA pomiędzy rfcomm_mutex i hdev->lock.

Funkcja rfcomm_security_cfm() jest wywoływana ze ścieżki zdarzenia HCI, która już
trzyma hdev->lock:

hci_rx_work()
hci_event_packet()
hci_cc_read_enc_key_size() [hdev->blokada]
hci_encrypt_cfm() [hci_cb_list_lock]
rfcomm_security_cfm() [rfcomm_mutex]

podczas gdy funkcja RFCOMM connect() z przestrzeni użytkownika pobiera te same dwie blokady
w drugą stronę:

rfcomm_sock_connect()
rfcomm_dlc_open() [rfcomm_mutex]
__rfcomm_dlc_open()
rfcomm_session_create()
kernel_connect()
l2cap_sock_connect()
l2cap_chan_connect() [hdev->blokada]

OSTRZEŻENIE: wykryto możliwą zależność blokowania cyklicznego
kworker/u131:1/1128 próbuje uzyskać blokadę:
rfcomm_mutex, pod adresem: rfcomm_security_cfm+0x31/0x3e0 [rfcomm]
ale zadanie już blokuje:
hci_cb_list_lock, pod adresem: hci_cc_read_enc_key_size+0x1d2/0xcc0
Łańcuch istnieje:
rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock

hci_auth_complete_evt() i hci_encrypt_change_evt() osiągają wywołanie zwrotne
w ten sam sposób.

Obydwa zamówienia muszą być widoczne w tym samym bucie, dlatego BR/EDR
Samo połączenie nie wystarczy, aby to pokazać: sesja skonfigurowana przez
strona zdalna jest tworzona przez rfcomm_accept_connection() w krfcommd, który
wywołuje kernel_accept() i nigdy nie pobiera hdev->lock z rfcomm_mutex.
Podłączenie urządzenia, które uwierzytelnia i szyfruje łącze, a następnie
wywołanie funkcji connect() na gnieździe RFCOMM pod dowolnym adresem - połączenie
nie musi się udać, kolejność jest zapisywana przed upływem limitu czasu strony
- melduje to za każdym razem.

Tylko gniazdo sesyjne musi być połączone z trzymanym zamkiem i to
nie: nic innego nie może zobaczyć gniazda przed jego założeniem
lista sesji. Więc najpierw podłącz go, a potem weź rfcomm_mutex,
co raczej na dobre usuwa kolejność rfcomm_mutex -> hdev->lock
niż utrzymywanie ścieżki zdarzenia HCI poza rfcomm_mutex.

rfcomm_session_create() staje się rfcomm_session_connect(), co powoduje powrót
podłączone gniazdo bez dotykania listy sesji, oraz
rfcomm_dlc_open() dodaje sesję, gdy ponownie utrzyma blokadę. Jeśli
inny otwieracz dodał sesję dla tej samej pary, podczas gdy to gniazdo było
podczas łączenia, ta sesja jest używana, a to gniazdo jest odrzucane.
__rfcomm_dlc_open() pobiera teraz sesję, której powinna używać, i jej stan
sprawdzenie działa po ponownym uzyskaniu zamka, więc DLC, które zostało otwarte lub
zamknięte w międzyczasie są nadal obsługiwane.

Za pośrednictwem istniejącego łącza ACL połączenie może zostać zakończone przed
sesja dociera do listy, a wybudzenie z wywołania zwrotnego gniazda następuje
następnie utracone, więc krfcommd zostanie obudzony, gdy sesja będzie widoczna.

Podłączenie bez blokady otwiera okno, w którym można umieścić gniazdo
zamknięte. DLC nie jest jeszcze w sesji, więc rfcomm_dlc_close() znajduje
nic do zrobienia i wraca bez dotykania tego, i rfcomm_dlc_open()
następnie dołączy DLC, którego właściciel zniknął. rfcomm_dlc_close() teraz
zaznacza takie DLC za pomocą RFCOMM_CLOSED, a rfcomm_dlc_open() sprawdza
mark, gdy ponownie zatrzyma rfcomm_mutex i zamiast tego upuści gniazdo
dołączenie DLC. Znak jest usuwany, gdy rozpoczyna się otwarcie, a więc DLC
które są ponownie wykorzystywane, nie ma to wpływu. Dotyczy to zarówno osób dzwoniących z
rfcomm_dlc_open(), gniazdo i warstwa tty.

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex

An RFCOMM connect() issued while a BR/EDR link is being authenticated
makes lockdep report a circular dependency, and the reported cycle is a
real AB/BA between rfcomm_mutex and hdev->lock.

rfcomm_security_cfm() is called from the HCI event path, which already
holds hdev->lock:

hci_rx_work()
hci_event_packet()
hci_cc_read_enc_key_size() [hdev->lock]
hci_encrypt_cfm() [hci_cb_list_lock]
rfcomm_security_cfm() [rfcomm_mutex]

while an RFCOMM connect() from userspace takes the same two locks the
other way round:

rfcomm_sock_connect()
rfcomm_dlc_open() [rfcomm_mutex]
__rfcomm_dlc_open()
rfcomm_session_create()
kernel_connect()
l2cap_sock_connect()
l2cap_chan_connect() [hdev->lock]

WARNING: possible circular locking dependency detected
kworker/u131:1/1128 is trying to acquire lock:
rfcomm_mutex, at: rfcomm_security_cfm+0x31/0x3e0 [rfcomm]
but task is already holding lock:
hci_cb_list_lock, at: hci_cc_read_enc_key_size+0x1d2/0xcc0
Chain exists of:
rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock

hci_auth_complete_evt() and hci_encrypt_change_evt() reach the callback
the same way.

Both orders have to be seen in the same boot, which is why a BR/EDR
connection alone is not enough to show it: a session set up by the
remote side is created by rfcomm_accept_connection() in krfcommd, which
calls kernel_accept() and never takes hdev->lock under rfcomm_mutex.
Connecting a device that authenticates and encrypts the link and then
calling connect() on an RFCOMM socket towards any address - the connect
does not have to succeed, the order is recorded before the page timeout
- reports it every time.

Only the session socket has to be connected with the lock held, and it
does not: nothing else can see the socket before it is put on the
session list. So connect it first and take rfcomm_mutex afterwards,
which removes the rfcomm_mutex -> hdev->lock order for good, rather
than keeping the HCI event path out of rfcomm_mutex.

rfcomm_session_create() becomes rfcomm_session_connect(), which returns
the connected socket without touching the session list, and
rfcomm_dlc_open() adds the session once it holds the lock again. If
another opener added a session for the same pair while this socket was
connecting, that session is used and this socket is dropped.
__rfcomm_dlc_open() now takes the session it should use, and its state
check runs after the lock is re-acquired, so a DLC that was opened or
closed in the meantime is still handled.

Over an existing ACL link the connection can complete before the
session reaches the list, and the wakeup from the socket callback is
then lost, so krfcommd is woken once the session is visible.

Connecting without the lock opens a window in which the socket can be
closed. The DLC is not on a session yet, so rfcomm_dlc_close() finds
nothing to do and returns without touching it, and rfcomm_dlc_open()
would then attach a DLC whose owner is gone. rfcomm_dlc_close() now
marks such a DLC with RFCOMM_CLOSED, and rfcomm_dlc_open() checks the
mark once it holds rfcomm_mutex again and drops the socket instead of
attaching the DLC. The mark is cleared when an open starts, so a DLC
that is reused is not affected. This covers both callers of
rfcomm_dlc_open(), the socket and the tty layer.

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve