KASAN reports that there's a use-after-free in
hci_remove_adv_monitor(). Trawling through the disassembly, you can
see that the complaint is from the access in bt_dev_dbg() under the
HCI_ADV_MONITOR_EXT_MSFT case. The problem case happens because
msft_remove_monitor() can end up freeing the monitor
structure. Specifically:
hci_remove_adv_monitor() ->
msft_remove_monitor() ->
msft_remove_monitor_sync() ->
msft_le_cancel_monitor_advertisement_cb() ->
hci_free_adv_monitor()
Let's fix the problem by just stashing the relevant data when it's
still valid.
Fixes: 7cf5c2978f23 ("Bluetooth: hci_sync: Refactor remove Adv Monitor")
Signed-off-by: Douglas Anderson <[email protected]>
---
net/bluetooth/hci_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 48917c68358d..dbb2043a9112 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1972,6 +1972,7 @@ static int hci_remove_adv_monitor(struct hci_dev *hdev,
struct adv_monitor *monitor)
{
int status = 0;
+ int handle;
switch (hci_get_adv_monitor_offload_ext(hdev)) {
case HCI_ADV_MONITOR_EXT_NONE: /* also goes here when powered off */
@@ -1980,9 +1981,10 @@ static int hci_remove_adv_monitor(struct hci_dev *hdev,
goto free_monitor;
case HCI_ADV_MONITOR_EXT_MSFT:
+ handle = monitor->handle;
status = msft_remove_monitor(hdev, monitor);
bt_dev_dbg(hdev, "%s remove monitor %d msft status %d",
- hdev->name, monitor->handle, status);
+ hdev->name, handle, status);
break;
}
--
2.41.0.255.g8b1d071c50-goog
Hi Douglas,
On Fri, Jun 30, 2023 at 2:40 PM Douglas Anderson <[email protected]> wrote:
>
> KASAN reports that there's a use-after-free in
> hci_remove_adv_monitor(). Trawling through the disassembly, you can
> see that the complaint is from the access in bt_dev_dbg() under the
> HCI_ADV_MONITOR_EXT_MSFT case. The problem case happens because
> msft_remove_monitor() can end up freeing the monitor
> structure. Specifically:
> hci_remove_adv_monitor() ->
> msft_remove_monitor() ->
> msft_remove_monitor_sync() ->
> msft_le_cancel_monitor_advertisement_cb() ->
> hci_free_adv_monitor()
>
> Let's fix the problem by just stashing the relevant data when it's
> still valid.
>
> Fixes: 7cf5c2978f23 ("Bluetooth: hci_sync: Refactor remove Adv Monitor")
> Signed-off-by: Douglas Anderson <[email protected]>
> ---
>
> net/bluetooth/hci_core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 48917c68358d..dbb2043a9112 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -1972,6 +1972,7 @@ static int hci_remove_adv_monitor(struct hci_dev *hdev,
> struct adv_monitor *monitor)
> {
> int status = 0;
> + int handle;
>
> switch (hci_get_adv_monitor_offload_ext(hdev)) {
> case HCI_ADV_MONITOR_EXT_NONE: /* also goes here when powered off */
> @@ -1980,9 +1981,10 @@ static int hci_remove_adv_monitor(struct hci_dev *hdev,
> goto free_monitor;
>
> case HCI_ADV_MONITOR_EXT_MSFT:
> + handle = monitor->handle;
> status = msft_remove_monitor(hdev, monitor);
> bt_dev_dbg(hdev, "%s remove monitor %d msft status %d",
> - hdev->name, monitor->handle, status);
> + hdev->name, handle, status);
Just move the call to bt_dev_dbg under msft_remove_monitor, also there
is no reason to print hdev->name since bt_dev_dbg already does that so
while at it we can probably fix this as well.
> break;
> }
>
> --
> 2.41.0.255.g8b1d071c50-goog
>
--
Luiz Augusto von Dentz
Hi,
On Fri, Jun 30, 2023 at 2:55 PM Luiz Augusto von Dentz
<[email protected]> wrote:
>
> Hi Douglas,
>
> On Fri, Jun 30, 2023 at 2:40 PM Douglas Anderson <[email protected]> wrote:
> >
> > KASAN reports that there's a use-after-free in
> > hci_remove_adv_monitor(). Trawling through the disassembly, you can
> > see that the complaint is from the access in bt_dev_dbg() under the
> > HCI_ADV_MONITOR_EXT_MSFT case. The problem case happens because
> > msft_remove_monitor() can end up freeing the monitor
> > structure. Specifically:
> > hci_remove_adv_monitor() ->
> > msft_remove_monitor() ->
> > msft_remove_monitor_sync() ->
> > msft_le_cancel_monitor_advertisement_cb() ->
> > hci_free_adv_monitor()
> >
> > Let's fix the problem by just stashing the relevant data when it's
> > still valid.
> >
> > Fixes: 7cf5c2978f23 ("Bluetooth: hci_sync: Refactor remove Adv Monitor")
> > Signed-off-by: Douglas Anderson <[email protected]>
> > ---
> >
> > net/bluetooth/hci_core.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> > index 48917c68358d..dbb2043a9112 100644
> > --- a/net/bluetooth/hci_core.c
> > +++ b/net/bluetooth/hci_core.c
> > @@ -1972,6 +1972,7 @@ static int hci_remove_adv_monitor(struct hci_dev *hdev,
> > struct adv_monitor *monitor)
> > {
> > int status = 0;
> > + int handle;
> >
> > switch (hci_get_adv_monitor_offload_ext(hdev)) {
> > case HCI_ADV_MONITOR_EXT_NONE: /* also goes here when powered off */
> > @@ -1980,9 +1981,10 @@ static int hci_remove_adv_monitor(struct hci_dev *hdev,
> > goto free_monitor;
> >
> > case HCI_ADV_MONITOR_EXT_MSFT:
> > + handle = monitor->handle;
> > status = msft_remove_monitor(hdev, monitor);
> > bt_dev_dbg(hdev, "%s remove monitor %d msft status %d",
> > - hdev->name, monitor->handle, status);
> > + hdev->name, handle, status);
>
> Just move the call to bt_dev_dbg under msft_remove_monitor,
Sure. I wasn't sure how much the order of the printout matters, but if
it doesn't then just putting the print first makes sense. Done in v2.
> also there
> is no reason to print hdev->name since bt_dev_dbg already does that so
> while at it we can probably fix this as well.
I made that a separate patch just to keep it cleaner. I also fixed the
"add" function which has the same issue.
-Doug
Hi,
On Fri, Jun 30, 2023 at 3:11 PM Doug Anderson <[email protected]> wrote:
>
> > > @@ -1980,9 +1981,10 @@ static int hci_remove_adv_monitor(struct hci_dev *hdev,
> > > goto free_monitor;
> > >
> > > case HCI_ADV_MONITOR_EXT_MSFT:
> > > + handle = monitor->handle;
> > > status = msft_remove_monitor(hdev, monitor);
> > > bt_dev_dbg(hdev, "%s remove monitor %d msft status %d",
> > > - hdev->name, monitor->handle, status);
> > > + hdev->name, handle, status);
> >
> > Just move the call to bt_dev_dbg under msft_remove_monitor,
>
> Sure. I wasn't sure how much the order of the printout matters, but if
> it doesn't then just putting the print first makes sense. Done in v2.
So I assumed that this meant you just wanted me to switch the order,
which I did for v2. ...but then Manish pointed out that meant I wasn't
printing the right status.
Looking again, maybe you meant that I should move the debug statement
into the msft_remove_monitor(). I'm not convinced that's any cleaner.
That would mean adding an "exit" label to that function just for the
printout. It also makes the printout asymmetric with other similar
printouts.
I'm going back to v1 here. If I've misunderstood then I guess I can
always spin again. :-/
-Doug
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=761687
---Test result---
Test Summary:
CheckPatch PASS 0.82 seconds
GitLint PASS 0.39 seconds
SubjectPrefix PASS 0.14 seconds
BuildKernel PASS 40.34 seconds
CheckAllWarning PASS 43.82 seconds
CheckSparse PASS 49.54 seconds
CheckSmatch PASS 133.50 seconds
BuildKernel32 PASS 38.92 seconds
TestRunnerSetup PASS 548.39 seconds
TestRunner_l2cap-tester PASS 16.87 seconds
TestRunner_iso-tester PASS 30.80 seconds
TestRunner_bnep-tester PASS 7.45 seconds
TestRunner_mgmt-tester PASS 158.27 seconds
TestRunner_rfcomm-tester PASS 11.48 seconds
TestRunner_sco-tester PASS 12.65 seconds
TestRunner_ioctl-tester PASS 12.88 seconds
TestRunner_mesh-tester PASS 9.09 seconds
TestRunner_smp-tester PASS 10.63 seconds
TestRunner_userchan-tester PASS 7.63 seconds
IncrementalBuild PASS 36.82 seconds
---
Regards,
Linux Bluetooth