linux-kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <87cyezah71.wl-tiwai@suse.de>
Date: Sun, 02 Mar 2025 10:57:06 +0100
From: Takashi Iwai <tiwai@...e.de>
To: Luiz Augusto von Dentz <luiz.von.dentz@...el.com>
Cc: linux-bluetooth@...r.kernel.org,
    linux-kernel@...r.kernel.org

Hi Luiz,

due to the CVE assignment, I stumbled on the recent fix for BT
hci_core, the commit 4d94f0555827 ("Bluetooth: hci_core: Fix sleeping
function called from invalid context"), and wonder whether it's really
safe.

As already asked question at the patch review:
  https://patchwork.kernel.org/comment/26147087/
the code allows the callbacks to be called even after
hci_unregister_cb() returns.

Your assumption was that it's never called without the module removal,
but isn't hci_unregister_cb() also called from iso_exit() which can be
triggered via set_iso_socket_func() in mgmt.c?  Also, any 3rd party
module could call hci_unregister_cb() in a wild way, too -- even if
the function still remains, it doesn't mean that you can call it
safely if the caller already assumes it being unregistered.

In addition to that, I feel what the patch does as a bit too
heavy-lifting: it does kmalloc() and copy the whole hci_cb object,
which isn't quite small for each.  If the callback is still safe to
call after RCU protection, you may just keep the hci_cb pointer
instead of copying the whole content, too?

I couldn't find v1 patch in the patchwork, so not sure whether this
has been already discussed.  If so, let me know.

Thanks!

Takashi