linux-kernel - Re: [PATCH] Bluetooth: hci_ldisc: Postpone HCI_UART_PROTO_READY bit set in hci_uart_set

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190224011228.GB32385@laptop.jcline.org>
Date:   Sat, 23 Feb 2019 20:12:28 -0500
From:   Jeremy Cline <jcline@...hat.com>
To:     Kefeng Wang <wangkefeng.wang@...wei.com>
Cc:     Marcel Holtmann <marcel@...tmann.org>,
        linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
        Johan Hedberg <johan.hedberg@...il.com>,
        syzbot+899a33dc0fa0dbaf06a6@...kaller.appspotmail.com
Subject: Re: [PATCH] Bluetooth: hci_ldisc: Postpone HCI_UART_PROTO_READY bit
 set in hci_uart_set_proto()

On Sat, Feb 23, 2019 at 12:33:27PM +0800, Kefeng Wang wrote:
> task A:                                task B:
> hci_uart_set_proto                     flush_to_ldisc
>  - p->open(hu) -> h5_open  //alloc h5  - receive_buf
>  - set_bit HCI_UART_PROTO_READY         - tty_port_default_receive_buf
>  - hci_uart_register_dev                 - tty_ldisc_receive_buf
>                                           - hci_uart_tty_receive
> 				           - test_bit HCI_UART_PROTO_READY
> 				            - h5_recv
>  - clear_bit HCI_UART_PROTO_READY             while() {
>  - p->open(hu) -> h5_close //free h5

I think commit 32a7b4cbe93b ("Bluetooth: hci_ldisc: Initialize hci_dev
before open()") in made this worse by inadvertently changing this from

- clear_bit HCI_UART_PROTO_READY
- p->close(hu) -> h5_close //free h5

to

- p->close(hu) -> h5_close //free h5
- clear_bit HCI_UART_PROTO_READY

because the close call got moved into hci_uart_register_dev(). I guess
that made the race window sufficiently wide to be easily reproducible,
but it looks like it was present even before that commit.

> 				              - h5_rx_3wire_hdr
> 				               - h5_reset()  //use-after-free
>                                               }
> 
> It could use ioctl to set hci uart proto, but there is
> a use-after-free issue when hci_uart_register_dev() fail in
> hci_uart_set_proto(), see stack above, fix this by setting
> HCI_UART_PROTO_READY bit only when hci_uart_register_dev()
> return success.
> 
> Reported-by: syzbot+899a33dc0fa0dbaf06a6@...kaller.appspotmail.com
> Signed-off-by: Kefeng Wang <wangkefeng.wang@...wei.com>
> ---
>  drivers/bluetooth/hci_ldisc.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
> index 4918fefc4a6f..9562e72c1ae5 100644
> --- a/drivers/bluetooth/hci_ldisc.c
> +++ b/drivers/bluetooth/hci_ldisc.c
> @@ -696,14 +696,13 @@ static int hci_uart_set_proto(struct hci_uart *hu, int id)
>  		return -EPROTONOSUPPORT;
>  
>  	hu->proto = p;
> -	set_bit(HCI_UART_PROTO_READY, &hu->flags);
>  
>  	err = hci_uart_register_dev(hu);
>  	if (err) {
> -		clear_bit(HCI_UART_PROTO_READY, &hu->flags);
>  		return err;
>  	}
>  
> +	set_bit(HCI_UART_PROTO_READY, &hu->flags);
>  	return 0;
>  }
>  
> -- 
> 2.20.1
> 

For what it's worth:

Reviewed-by: Jeremy Cline <jcline@...hat.com>