Re: memory leak in kobject_set_name_vargs (2)

Re: memory leak in kobject_set_name_vargs (2)

[Dmitry Vyukov]

On Wed, Jul 24, 2019 at 1:08 AM syzbot
<syzbot+ad8ca40ecd77896d51e2@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:    3bfe1fc4 Merge tag 'for-5.3/dm-changes-2' of git://git.ker..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=130322afa00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=dcfc65ee492509c6
> dashboard link: https://syzkaller.appspot.com/bug?extid=ad8ca40ecd77896d51e2
> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=135cbed0600000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14dd4e34600000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+ad8ca40ecd77896d51e2@syzkaller.appspotmail.com

+net/ipv6/ip6_vti.c maintainers

> BUG: memory leak
> unreferenced object 0xffff88810cc5d860 (size 32):
>    comm "syz-executor938", pid 7153, jiffies 4294945400 (age 8.020s)
>    hex dump (first 32 bytes):
>      69 70 36 5f 76 74 69 31 00 2f 37 31 35 33 00 00  ip6_vti1./7153..
>      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    backtrace:
>      [<000000000800471f>] kmemleak_alloc_recursive
> /./include/linux/kmemleak.h:43 [inline]
>      [<000000000800471f>] slab_post_alloc_hook /mm/slab.h:522 [inline]
>      [<000000000800471f>] slab_alloc /mm/slab.c:3319 [inline]
>      [<000000000800471f>] __do_kmalloc /mm/slab.c:3653 [inline]
>      [<000000000800471f>] __kmalloc_track_caller+0x165/0x300 /mm/slab.c:3670
>      [<000000007a2eef8e>] kstrdup+0x3a/0x70 /mm/util.c:53
>      [<00000000a309e483>] kstrdup_const+0x48/0x60 /mm/util.c:75
>      [<00000000cf8dc39b>] kvasprintf_const+0x7e/0xe0 /lib/kasprintf.c:48
>      [<000000005a964730>] kobject_set_name_vargs+0x40/0xe0 /lib/kobject.c:289
>      [<00000000e2a9ccdf>] dev_set_name+0x63/0x90 /drivers/base/core.c:1915
>      [<000000007bc7b1da>] netdev_register_kobject+0x5a/0x1b0
> /net/core/net-sysfs.c:1727
>      [<00000000637b4645>] register_netdevice+0x397/0x600 /net/core/dev.c:8723
>      [<0000000038b21fdc>] vti6_tnl_create2+0x47/0xb0 /net/ipv6/ip6_vti.c:189
>      [<0000000023231475>] vti6_tnl_create /net/ipv6/ip6_vti.c:229 [inline]
>      [<0000000023231475>] vti6_locate /net/ipv6/ip6_vti.c:277 [inline]
>      [<0000000023231475>] vti6_locate+0x244/0x2c0 /net/ipv6/ip6_vti.c:255
>      [<000000006ebf0a44>] vti6_ioctl+0x17f/0x390 /net/ipv6/ip6_vti.c:802
>      [<00000000077406fa>] dev_ifsioc+0x324/0x460 /net/core/dev_ioctl.c:322
>      [<00000000465d817c>] dev_ioctl+0x157/0x45e /net/core/dev_ioctl.c:514
>      [<00000000e2472af6>] sock_ioctl+0x394/0x480 /net/socket.c:1099
>      [<0000000024234c3b>] vfs_ioctl /fs/ioctl.c:46 [inline]
>      [<0000000024234c3b>] file_ioctl /fs/ioctl.c:509 [inline]
>      [<0000000024234c3b>] do_vfs_ioctl+0x62a/0x810 /fs/ioctl.c:696
>      [<0000000015b52ca4>] ksys_ioctl+0x86/0xb0 /fs/ioctl.c:713
>
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> 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
>
> --
> 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@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/000000000000edcb3c058e6143d5%40google.com.

Re: memory leak in kobject_set_name_vargs (2)

[syzbot]

syzbot has bisected this bug to:

commit 0e034f5c4bc408c943f9c4a06244415d75d7108c
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed May 18 18:51:25 2016 +0000

     iwlwifi: fix mis-merge that breaks the driver

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=10f955f0600000
start commit:   3bfe1fc4 Merge tag 'for-5.3/dm-changes-2' of git://git.ker..
git tree:       upstream
final crash:    https://syzkaller.appspot.com/x/report.txt?x=12f955f0600000
console output: https://syzkaller.appspot.com/x/log.txt?x=14f955f0600000
kernel config:  https://syzkaller.appspot.com/x/.config?x=dcfc65ee492509c6
dashboard link: https://syzkaller.appspot.com/bug?extid=ad8ca40ecd77896d51e2
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=135cbed0600000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14dd4e34600000

Reported-by: syzbot+ad8ca40ecd77896d51e2@syzkaller.appspotmail.com
Fixes: 0e034f5c4bc4 ("iwlwifi: fix mis-merge that breaks the driver")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: memory leak in kobject_set_name_vargs (2)

[Linus Torvalds]

On Fri, Jul 26, 2019 at 4:26 PM syzbot
<syzbot+ad8ca40ecd77896d51e2@syzkaller.appspotmail.com> wrote:
>
> syzbot has bisected this bug to:
>
> commit 0e034f5c4bc408c943f9c4a06244415d75d7108c
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Wed May 18 18:51:25 2016 +0000
>
>      iwlwifi: fix mis-merge that breaks the driver

While this bisection looks more likely than the other syzbot entry
that bisected to a version change, I don't think it is correct eitger.

The bisection ended up doing a lot of "git bisect skip" because of the

    undefined reference to `nf_nat_icmp_reply_translation'

issue. Also, the memory leak doesn't seem to be entirely reliable:
when the bisect does 10 runs to verify that some test kernel is bad,
there are a couple of cases where only one or two of the ten run
failed.

Which makes me wonder if one or two of the "everything OK" runs were
actually buggy, but just happened to have all ten pass...

               Linus

Re: memory leak in kobject_set_name_vargs (2)

[Qian Cai]

> On Jul 26, 2019, at 10:29 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> On Fri, Jul 26, 2019 at 4:26 PM syzbot
> <syzbot+ad8ca40ecd77896d51e2@syzkaller.appspotmail.com> wrote:
>> 
>> syzbot has bisected this bug to:
>> 
>> commit 0e034f5c4bc408c943f9c4a06244415d75d7108c
>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>> Date:   Wed May 18 18:51:25 2016 +0000
>> 
>>     iwlwifi: fix mis-merge that breaks the driver
> 
> While this bisection looks more likely than the other syzbot entry
> that bisected to a version change, I don't think it is correct eitger.
> 
> The bisection ended up doing a lot of "git bisect skip" because of the
> 
>    undefined reference to `nf_nat_icmp_reply_translation'
> 
> issue. Also, the memory leak doesn't seem to be entirely reliable:
> when the bisect does 10 runs to verify that some test kernel is bad,
> there are a couple of cases where only one or two of the ten run
> failed.
> 
> Which makes me wonder if one or two of the "everything OK" runs were
> actually buggy, but just happened to have all ten pass…

Real bisection should point to,

8ed633b9baf9e (“Revert "net-sysfs: Fix memory leak in netdev_register_kobject”")

I did encounter those memory leak and comes up with a similar fix in,

6b70fc94afd1 ("net-sysfs: Fix memory leak in netdev_register_kobject”)

but those error handling paths are tricky that seems nobody did much testing there, so it will
keep hitting other bugs in upper functions.

Re: memory leak in kobject_set_name_vargs (2)

[Dmitry Vyukov]

On Sat, Jul 27, 2019 at 4:29 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, Jul 26, 2019 at 4:26 PM syzbot
> <syzbot+ad8ca40ecd77896d51e2@syzkaller.appspotmail.com> wrote:
> >
> > syzbot has bisected this bug to:
> >
> > commit 0e034f5c4bc408c943f9c4a06244415d75d7108c
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date:   Wed May 18 18:51:25 2016 +0000
> >
> >      iwlwifi: fix mis-merge that breaks the driver
>
> While this bisection looks more likely than the other syzbot entry
> that bisected to a version change, I don't think it is correct eitger.
>
> The bisection ended up doing a lot of "git bisect skip" because of the
>
>     undefined reference to `nf_nat_icmp_reply_translation'
>
> issue. Also, the memory leak doesn't seem to be entirely reliable:
> when the bisect does 10 runs to verify that some test kernel is bad,
> there are a couple of cases where only one or two of the ten run
> failed.
>
> Which makes me wonder if one or two of the "everything OK" runs were
> actually buggy, but just happened to have all ten pass...


I agree this is unrelated.

Bisection of memory leaks is now turned off completely after a
week-long experiment (details:
https://groups.google.com/d/msg/syzkaller/sR8aAXaWEF4/k34t365JBgAJ)

FWIW 'git bisect skip' is not a problem in itself. If the bisection
will end up being inconclusive due to this, then syzbot will not
attribute it to any commit (won't send an email at all), it will just
show the commit range in the web UI for the bug.

Low probability wasn't the root cause as well, first runs ended with
10/10 precision:

bisecting cause commit starting from 3bfe1fc46794631366faa3ef075e1b0ff7ba120a
building syzkaller on 1656845f45f284c574eb4f8bfe85dd7916a47a3a
testing commit 3bfe1fc46794631366faa3ef075e1b0ff7ba120a with gcc (GCC) 8.1.0
all runs: crashed: memory leak in kobject_set_name_vargs
testing release v5.2
testing commit 0ecfebd2b52404ae0c54a878c872bb93363ada36 with gcc (GCC) 8.1.0
all runs: crashed: memory leak in kobject_set_name_vargs
testing release v5.1
testing commit e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd with gcc (GCC) 8.1.0
all runs: crashed: memory leak in kobject_set_name_vargs
testing release v5.0
testing commit 1c163f4c7b3f621efff9b28a47abb36f7378d783 with gcc (GCC) 8.1.0
all runs: crashed: memory leak in kobject_set_name_vargs
testing release v4.20
testing commit 8fe28cb58bcb235034b64cbbb7550a8a43fd88be with gcc (GCC) 8.1.0
all runs: crashed: memory leak in kobject_set_name_vargs
testing release v4.19
testing commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d with gcc (GCC) 8.1.0
all runs: crashed: memory leak in kobject_set_name_vargs

But it was distracted by other bugs and other memory leaks (which
reproduce with lower probability) and then the process went random
(which confirms the bisection analysis results).