| 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
| ||
|
Message-Id: <0CE94469-E35F-46CF-BD80-5145B86AA9B2@holtmann.org>
Date: Thu, 29 Jul 2021 21:49:31 +0200
From: Marcel Holtmann <marcel@...tmann.org>
To: Phi Nguyen <phind.uet@...il.com>
Cc: Dan Carpenter <dan.carpenter@...cle.com>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
Johan Hedberg <johan.hedberg@...il.com>,
linux-bluetooth <linux-bluetooth@...r.kernel.org>,
linux-kernel@...r.kernel.org
Subject: Re: memory leak in h4_recv_buf
Hi Phi,
>>>>>> syzbot found the following crash on:
>>>>>> HEAD commit: abf02e29 Merge tag 'pm-5.2-rc6' of
>>>>>> git://git.kernel.org/pu <http://git.kernel.org/pu>..
>>>>>> git tree: upstream
>>>>>> console output:
>>>>>> https://syzkaller.appspot.com/x/log.txt?x=1054e6b2a00000
>>>>>> <https://syzkaller.appspot.com/x/log.txt?x=1054e6b2a00000>
>>>>>> kernel config:
>>>>>> https://syzkaller.appspot.com/x/.config?x=56f1da14935c3cce
>>>>>> <https://syzkaller.appspot.com/x/.config?x=56f1da14935c3cce>
>>>>>> dashboard link:
>>>>>> https://syzkaller.appspot.com/bug?extid=97388eb9d31b997fe1d0
>>>>>> <https://syzkaller.appspot.com/bug?extid=97388eb9d31b997fe1d0>
>>>>>> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>>>>>> syz repro:
>>>>>> https://syzkaller.appspot.com/x/repro.syz?x=1073d8aaa00000
>>>>>> <https://syzkaller.appspot.com/x/repro.syz?x=1073d8aaa00000>
>>>>>> C reproducer:
>>>>>> https://syzkaller.appspot.com/x/repro.c?x=17b36fbea00000
>>>>>> <https://syzkaller.appspot.com/x/repro.c?x=17b36fbea00000>
>>>>>> IMPORTANT: if you fix the bug, please add the following tag to the
>>>>>> commit:
>>>>>> Reported-by: syzbot+97388e...@...kaller.appspotmail.com
>>>>>> program
>>>>>> BUG: memory leak
>>>>>> unreferenced object 0xffff88810991fa00 (size 224):
>>>>>> comm "syz-executor739", pid 7080, jiffies 4294949854 (age 18.640s)
>>>>>> hex dump (first 32 bytes):
>>>>>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>>>>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>>>>> backtrace:
>>>>>> [<00000000da42c09f>] kmemleak_alloc_recursive
>>>>>> include/linux/kmemleak.h:43 [inline]
>>>>>> [<00000000da42c09f>] slab_post_alloc_hook mm/slab.h:439 [inline]
>>>>>> [<00000000da42c09f>] slab_alloc_node mm/slab.c:3269 [inline]
>>>>>> [<00000000da42c09f>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
>>>>>> [<00000000f6fbcf84>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
>>>>>> [<00000000ea93fc4c>] alloc_skb include/linux/skbuff.h:1054 [inline]
>>>>>> [<00000000ea93fc4c>] bt_skb_alloc include/net/bluetooth/bluetooth.h:339
>>>>>> [inline]
>>>>>> [<00000000ea93fc4c>] h4_recv_buf+0x26d/0x450
>>>>>> drivers/bluetooth/hci_h4.c:182
>>>>>> [<00000000e0312475>] h4_recv+0x51/0xb0 drivers/bluetooth/hci_h4.c:116
>>>>>> [<00000000ebf11fab>] hci_uart_tty_receive+0xba/0x200
>>>>>> drivers/bluetooth/hci_ldisc.c:592
>>>>>> [<0000000095e1216e>] tiocsti drivers/tty/tty_io.c:2195 [inline]
>>>>>> [<0000000095e1216e>] tty_ioctl+0x81c/0xa30 drivers/tty/tty_io.c:2571
>>>>>> [<000000009fa523f0>] vfs_ioctl fs/ioctl.c:46 [inline]
>>>>>> [<000000009fa523f0>] file_ioctl fs/ioctl.c:509 [inline]
>>>>>> [<000000009fa523f0>] do_vfs_ioctl+0x62a/0x810 fs/ioctl.c:696
>>>>>> [<000000000cebb5d9>] ksys_ioctl+0x86/0xb0 fs/ioctl.c:713
>>>>>> [<000000001630008a>] __do_sys_ioctl fs/ioctl.c:720 [inline]
>>>>>> [<000000001630008a>] __se_sys_ioctl fs/ioctl.c:718 [inline]
>>>>>> [<000000001630008a>] __x64_sys_ioctl+0x1e/0x30 fs/ioctl.c:718
>>>>>> [<00000000c62091e3>] do_syscall_64+0x76/0x1a0
>>>>>> arch/x86/entry/common.c:301
>>>>>> [<000000005c213625>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>>>>> BUG: memory leak
>>>>>> unreferenced object 0xffff8881204f4400 (size 1024):
>>>>>> comm "syz-executor739", pid 7080, jiffies 4294949854 (age 18.640s)
>>>>>> hex dump (first 32 bytes):
>>>>>> 6c 69 62 75 64 65 76 00 fe ed ca fe 28 00 00 00 libudev.....(...
>>>>>> 28 00 00 00 a0 00 00 00 52 ca da 77 00 00 00 00 (.......R..w....
>>>>>> backtrace:
>>>>>> [<0000000034504843>] kmemleak_alloc_recursive
>>>>>> include/linux/kmemleak.h:43 [inline]
>>>>>> [<0000000034504843>] slab_post_alloc_hook mm/slab.h:439 [inline]
>>>>>> [<0000000034504843>] slab_alloc_node mm/slab.c:3269 [inline]
>>>>>> [<0000000034504843>] kmem_cache_alloc_node_trace+0x15b/0x2a0
>>>>>> mm/slab.c:3597
>>>>>> [<0000000056d30eb5>] __do_kmalloc_node mm/slab.c:3619 [inline]
>>>>>> [<0000000056d30eb5>] __kmalloc_node_track_caller+0x38/0x50
>>>>>> mm/slab.c:3634
>>>>>> [<00000000df40176c>] __kmalloc_reserve.isra.0+0x40/0xb0
>>>>>> net/core/skbuff.c:138
>>>>>> [<0000000035340e64>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
>>>>>> [<00000000ea93fc4c>] alloc_skb include/linux/skbuff.h:1054 [inline]
>>>>>> [<00000000ea93fc4c>] bt_skb_alloc include/net/bluetooth/bluetooth.h:339
>>>>>> [inline]
>>>>>> [<00000000ea93fc4c>] h4_recv_buf+0x26d/0x450
>>>>>> drivers/bluetooth/hci_h4.c:182
>>>>>> [<00000000e0312475>] h4_recv+0x51/0xb0 drivers/bluetooth/hci_h4.c:116
>>>>>> [<00000000ebf11fab>] hci_uart_tty_receive+0xba/0x200
>>>>>> drivers/bluetooth/hci_ldisc.c:592
>>>>>> [<0000000095e1216e>] tiocsti drivers/tty/tty_io.c:2195 [inline]
>>>>>> [<0000000095e1216e>] tty_ioctl+0x81c/0xa30 drivers/tty/tty_io.c:2571
>>>>>> [<000000009fa523f0>] vfs_ioctl fs/ioctl.c:46 [inline]
>>>>>> [<000000009fa523f0>] file_ioctl fs/ioctl.c:509 [inline]
>>>>>> [<000000009fa523f0>] do_vfs_ioctl+0x62a/0x810 fs/ioctl.c:696
>>>>>> [<000000000cebb5d9>] ksys_ioctl+0x86/0xb0 fs/ioctl.c:713
>>>>>> [<000000001630008a>] __do_sys_ioctl fs/ioctl.c:720 [inline]
>>>>>> [<000000001630008a>] __se_sys_ioctl fs/ioctl.c:718 [inline]
>>>>>> [<000000001630008a>] __x64_sys_ioctl+0x1e/0x30 fs/ioctl.c:718
>>>>>> [<00000000c62091e3>] do_syscall_64+0x76/0x1a0
>>>>>> arch/x86/entry/common.c:301
>>>>>> [<000000005c213625>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>>>>> ---
>>>>>> This bug is generated by a bot. It may contain errors.
>>>>>> See https://goo.gl/tpsmEJ <https://goo.gl/tpsmEJ> for more
>>>>>> information about syzbot.
>>>>>> syzbot engineers can be reached at syzk...@...glegroups.com.
>>>>>> syzbot will keep track of this bug report. See:
>>>>>> https://goo.gl/tpsmEJ#status <https://goo.gl/tpsmEJ#status> for how
>>>>>> to communicate with syzbot.
>>>>>> syzbot can test patches for this bug, for details see:
>>>>>> https://goo.gl/tpsmEJ#testing-patches
>>>>>> <https://goo.gl/tpsmEJ#testing-patches>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@...glegroups.com <mailto:syzkaller-bugs+unsubscribe@...glegroups.com>.
>>>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/d71a274f-fdeb-4da1-898e-06f6944e04dan%40googlegroups.com <https://groups.google.com/d/msgid/syzkaller-bugs/d71a274f-fdeb-4da1-898e-06f6944e04dan%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>>>
>>>>> The reason of this memory leak is tty_ldisc_receive_buf() and tiocsti()
>>>>> can access the h4->rx_skb concurrently by calling
>>>>> hci_uart_tty_receive(), so the rx_skb be overwritten without
>>>>> deallocating. There used to be an spin_lock in hci_uart_tty_receive(),
>>>>> but it was removed by commit 7649ffaff1cfe(Bluetooth: Remove useless
>>>>> rx_lock spinlock).
>>>>
>>>> I don’t have that commit in my Linus’ tree. Where is it?
>>>>
>>>
>>> There is a typo in the git hash. It should be: 7649faff1cfe4 ("Bluetooth:
>>> Remove useless rx_lock spinlock").
>>>
>>>>> The commit message claims that hci_uart_tty_receive() was only called by
>>>>> flush_to_ldisc(), but it seems incorrect.
>>>>
>>>> That seems to be a larger problem in the TTY layer if its contract with its users have changed.
>>>
>>> The tiocsti() function has an ancient comment which suggests that the
>>> documentation has always been wrong.
>>>
>>> * FIXME: may race normal receive processing
>> so what are we suppose to do now? Fix this in TTY layer or try to revert this patch?
>> And does it have to be spinlock or can we use a mutex? My knowledge of the TTY internal are limited and thus, I have no idea what we need to do here. However h4_recv_buf needs to be protected against concurrently calls.
>> Regards
>> Marcel
> Hi Marcel,
>
> So far, I have tested two fixes with syzbot
> The first one is to bring the spin lock back to hci_uart_tty_receive().
> The second one is to use tty_buffer_lock_exclusive() in tiocsti() (I based on the document in tty_buffer.c).
> These two can work well with the syzbot.
if we can fix it in the TTY layer, then that is my preference. If we can’t, then it would be good to know if we can use a mutex instead of spinlock.
Regards
Marcel
Powered by blists - more mailing lists