Re: [PATCH 4.9 02/31] Bluetooth: hci_ldisc: Postpone HCI_UART_PROTO_READY bit set in hci_uart_set_proto()

[Greg Kroah-Hartman]

On Fri, Nov 15, 2019 at 11:10:29AM -0500, Ralph Siemsen wrote:
> Hi Greg,
> 
> On Fri, Nov 15, 2019 at 02:20:31PM +0800, Greg Kroah-Hartman wrote:
> > From: Kefeng Wang <wangkefeng.wang@xxxxxxxxxx>
> > 
> > commit 56897b217a1d0a91c9920cb418d6b3fe922f590a upstream.
> > 
> > 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
> > 				              - 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@xxxxxxxxxxxxxxxxxxxxxxxxx
> > Signed-off-by: Kefeng Wang <wangkefeng.wang@xxxxxxxxxx>
> > Reviewed-by: Jeremy Cline <jcline@xxxxxxxxxx>
> > Signed-off-by: Marcel Holtmann <marcel@xxxxxxxxxxxx>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> 
> I was just about to ask why this had not been merged into 4.9. Spent a while
> searching archives for any discussion to explain its absence, but couldn't
> find anything. Also watched your kernel-recipes talk...
> 
> BTW, this also seems to be missing from 4.4 branch, although it was merged
> for 3.16 (per https://lore.kernel.org/stable/?q=Postpone+HCI).

Odd that it was merged into 3.16, perhaps it was done there because some
earlier patch added the problem?  I say this as I do not think this is
relevant for the 4.4.y kernel, do you?  Have you tried to apply this
patch there?

> I gather that the usual rule is that a fix must be in newer versions before
> it can go into older ones. Or at least, some patches were rejected on that
> basis. If this is in fact the policy, perhaps it could be added to
> stable-kernel-rules.rst ?

No, that's not why this was rejected.  I don't know why it didn't end up
in 4.9.y earlier, but for 4.4.y, it was not added there as I do not
think it actually is relevant (see above.)

thanks,

greg k-h