diff mbox series

Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_remove_adv_monitor()

Message ID 20230630143125.1.I3b7c8905728f3124576361ca35ed28e37f12f5d1@changeid
State New
Headers
Series Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_remove_adv_monitor() |

Commit Message

Doug Anderson June 30, 2023, 9:31 p.m. UTC 
  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 <dianders@chromium.org>
---

 net/bluetooth/hci_core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

Doug Anderson June 30, 2023, 10:11 p.m. UTC | #1 
Hi,

On Fri, Jun 30, 2023 at 2:55 PM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Douglas,
>
> On Fri, Jun 30, 2023 at 2:40 PM Douglas Anderson <dianders@chromium.org> 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 <dianders@chromium.org>
> > ---
> >
> >  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
Doug Anderson June 30, 2023, 10:30 p.m. UTC | #2 
Hi,

On Fri, Jun 30, 2023 at 3:11 PM Doug Anderson <dianders@chromium.org> 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
diff mbox series

Patch

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;
 	}