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
