PT-2026-52351 · Linux · Linux
Publicado
2026-06-25
·
Atualizado
2026-06-25
·
CVE-2026-53256
Nenhuma
Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: hold listener socket in rfcomm connect ind()
rfcomm get sock by channel() scans rfcomm sk list under the list lock,
but returns the selected listener after dropping that lock without
taking a reference. rfcomm connect ind() then locks the listener,
queues a child socket on it, and may notify it after unlocking it.
The buggy scenario involves two paths, with each column showing the
order within that path:
rfcomm connect ind(): listener close:
- Find parent in 1. close() enters rfcomm get sock by channel() rfcomm sock release().
- Drop rfcomm sk list.lock 2. rfcomm sock shutdown() without pinning parent. closes the listener.
- Call lock sock(parent) and 3. rfcomm sock kill() bt accept enqueue(parent, unlinks and puts parent. sk, true).
- Read parent flags and may 4. parent can be freed. call sk state change().
If close wins the race, parent can be freed before
rfcomm connect ind() reaches lock sock(), bt accept enqueue(), or the
deferred-setup callback.
Take a reference on the listener before leaving rfcomm sk list.lock.
After lock sock() succeeds, recheck that it is still in BT LISTEN
before queueing a child, cache the deferred-setup bit while the parent
is locked, and drop the reference after the last parent use.
KASAN reported a slab-use-after-free in lock sock nested() from
rfcomm connect ind(), with the freeing stack going through
rfcomm sock kill() and rfcomm sock release().
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux