lkml.org 
[lkml]   [2020]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v3] bluetooth: hci_h5: fix memory leak in h5_close
    From
    Date
    Hi,

    On 10/4/20 7:17 AM, Anant Thazhemadam wrote:
    > When h5_close() is called and !hu->serdev, h5 is directly freed.
    > However, h5->rx_skb is not freed before h5 is freed, which causes
    > a memory leak.
    > Freeing h5->rx_skb (when !hu->serdev) fixes this memory leak before
    > freeing h5.
    >
    > Fixes: ce945552fde4 ("Bluetooth: hci_h5: Add support for serdev enumerated devices")
    > Reported-by: syzbot+6ce141c55b2f7aafd1c4@syzkaller.appspotmail.com
    > Tested-by: syzbot+6ce141c55b2f7aafd1c4@syzkaller.appspotmail.com
    > Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
    > ---
    > Changes in v3:
    > * Free h5->rx_skb when !hu->serdev, and fix the memory leak
    > * Do not incorrectly and unnecessarily call serdev_device_close()
    >
    > Changes in v2:
    > * Fixed the Fixes tag
    >
    > Hans de Goede also suggested calling h5_reset_rx() on close (for both, !hu->serdev
    > and hu->serdev cases).
    > However, doing so seems to lead to a null-ptr-dereference error,
    > https://syzkaller.appspot.com/text?tag=CrashReport&x=136a9a5d900000,
    > and for this reason, it has not been implemented.
    >
    > Instead, directly freeing h5->rx_skb seems to suffice in preventing the memory leak
    > reported.
    > And since h5 is freed immediately after freeing h5->rx_skb, assigning h5->rx_skb to
    > be NULL isn't necessary.
    >
    > drivers/bluetooth/hci_h5.c | 4 +++-
    > 1 file changed, 3 insertions(+), 1 deletion(-)
    >
    > diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
    > index e41854e0d79a..171e55c080ce 100644
    > --- a/drivers/bluetooth/hci_h5.c
    > +++ b/drivers/bluetooth/hci_h5.c
    > @@ -248,8 +248,10 @@ static int h5_close(struct hci_uart *hu)
    > if (h5->vnd && h5->vnd->close)
    > h5->vnd->close(h5);
    >
    > - if (!hu->serdev)
    > + if (!hu->serdev){
    > + kfree_skb(h5->rx_skb);
    > kfree(h5);
    > + }
    >
    > return 0;
    > }
    >

    To fully fix the memleak you also need to add a kfree_skb(h5->rx_skb);
    call to the end of h5_serdev_remove(), because in the hu->serdev case
    that is where the h5 struct will be free-ed (it is free-ed after that
    function exits).

    Regards,

    Hans

    \
     
     \ /
      Last update: 2020-10-05 11:19    [W:4.179 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site