Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sat, 16 Nov 2019 15:56:14 +0800 | From | Greg Kroah-Hartman <> | Subject | Re: [PATCH 4.9 02/31] Bluetooth: hci_ldisc: Postpone HCI_UART_PROTO_READY bit set in hci_uart_set_proto() |
| |
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@huawei.com> > > > > 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@syzkaller.appspotmail.com > > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > > Reviewed-by: Jeremy Cline <jcline@redhat.com> > > Signed-off-by: Marcel Holtmann <marcel@holtmann.org> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > 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
| ![\](/images/icornerr.gif) |