netdev - Re: [PATCH 4.19 000/306] 4.19.87-stable review

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 26 Jan 2020 12:54:42 +0100 (CET)
From:   Lukas Bulwahn <lukas.bulwahn@...il.com>
To:     Jouni Högander <jouni.hogander@...kie.com>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        open list <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ben Hutchings <ben.hutchings@...ethink.co.uk>,
        linux- stable <stable@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        linux-fsdevel@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
        "David S. Miller" <davem@...emloft.net>, syzkaller@...glegroups.com
Subject: Re: [PATCH 4.19 000/306] 4.19.87-stable review


On Wed, 22 Jan 2020, Jouni Högander wrote:

> Greg Kroah-Hartman <gregkh@...uxfoundation.org> writes:
> >> > Now queued up, I'll push out -rc2 versions with this fix.
> >> >
> >> > greg k-h
> >> 
> >> We have also been informed about another regression these two commits
> >> are causing:
> >> 
> >> https://lore.kernel.org/lkml/ace19af4-7cae-babd-bac5-cd3505dcd874@I-love.SAKURA.ne.jp/
> >> 
> >> I suggest to drop these two patches from this queue, and give us a
> >> week to shake out the regressions of the change, and once ready, we
> >> can include the complete set of fixes to stable (probably in a week or
> >> two).
> >
> > Ok, thanks for the information, I've now dropped them from all of the
> > queues that had them in them.
> >
> > greg k-h
> 
> I have now run more extensive Syzkaller testing on following patches:
> 
> cb626bf566eb net-sysfs: Fix reference count leak
> ddd9b5e3e765 net-sysfs: Call dev_hold always in rx_queue_add_kobject
> e0b60903b434 net-sysfs: Call dev_hold always in netdev_queue_add_kobje
> 48a322b6f996 net-sysfs: fix netdev_queue_add_kobject() breakage
> b8eb718348b8 net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject
> 
> These patches are fixing couple of memory leaks including this one found
> by Syzbot: https://syzkaller.appspot.com/bug?extid=ad8ca40ecd77896d51e2
> 
> I can reproduce these memory leaks in following stable branches: 4.14,
> 4.19, and 5.4.
> 
> These are all now merged into net/master tree and based on my testing
> they are ready to be taken into stable branches as well.
>

+ syzkaller list
Jouni et. al, please drop Linus in further responses; Linus, it was wrong 
to add you to this thread in the first place (reason is explained below)

Jouni, thanks for investigating.

It raises the following questions and comments:

- Does the memory leak NOT appear on 4.9 and earlier LTS branches (or did 
you not check that)? If it does not appear, can you bisect it with the 
reproducer to the commit between 4.14 and 4.9?

- Do the reproducers you found with your syzkaller testing show the same 
behaviour (same bisection) as the reproducers from syzbot?

- I fear syzbot's automatic bisection on is wrong, and Linus' commit 
0e034f5c4bc4 ("iwlwifi: fix mis-merge that breaks the driver") is not to 
blame here; that commit did not cause the memory leak, but fixed some 
unrelated issue that simply confuses syzbot's automatic bisection.

Just FYI: Dmitry Vyukov's evaluation of the syzbot bisection shows that 
about 50% are wrong, e.g., due to multiple bugs being triggered with one 
reproducer and the difficulty of automatically identifying them of being 
different due to different root causes (despite the smart heuristics of 
syzkaller & syzbot). So, to identify the actual commit on which the memory 
leak first appeared, you need to bisect manually with your own judgement 
if the reported bug stack trace fits to the issue you investigating. Or 
you use syzbot's automatic bisection but then with a reduced kernel config 
that cannot be confused by other issues. You might possibly also hit a 
"beginning of time" in your bisection, where KASAN was simply not 
supported, then the initially causing commit can simply not determined by 
bisection with the reproducer and needs some code inspection and 
archaeology with git. Can you go ahead try to identify the correct commit 
for this issue?


Lukas