linux-kernel - Re: [clear_page] 0ad07c8104 BUG: unable to handle kernel NULL pointer dereference at 0000000000000040

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, 19 Feb 2017 09:06:51 +0800
From:   Fengguang Wu <fengguang.wu@...el.com>
To:     Borislav Petkov <bp@...e.de>
Cc:     LKP <lkp@...org>, lkml <linux-kernel@...r.kernel.org>,
        Ye Xiaolong <xiaolong.ye@...el.com>
Subject: Re: [clear_page] 0ad07c8104 BUG: unable to handle kernel NULL
 pointer dereference at 0000000000000040

On Sun, Feb 19, 2017 at 01:10:47AM +0100, Borislav Petkov wrote:
>Hey Fengguang,
>
>On Sun, Feb 19, 2017 at 07:29:50AM +0800, Fengguang Wu wrote:
>> Good point! I noticed it too while sending out the report. It'll be
>> showed as this in future:
>>
>>        https://github.com/0day-ci/linux/commits/Borislav-Petkov/x86-Optimize-clear_page/20170210-053052
>
>How about pointing to the patch directly?
>
>https://github.com/0day-ci/linux/commit/0ad07c8104eb5c12dfcb86581c1cc657183496cc

Yes if we add it as a line below the branch URL, it could be a time saver.

>> Sorry the 2nd report was send out manually and I only checked the
>> emails in my _current_ mbox. Since the previous report email has been
>> archived, it slipped through the duplication check.
>
>No worries - this was all a prelude to me hinting at the email-based
>talking to the bot :-)
>
>> CC Xiaolong. It's possible to automate the test-of-fixup-patches.
>> Firstly find out the original email report by the Message-ID being
>> replied to. Then fetch all the information required for deciding where
>> the patch should be applied to, parameters to auto-testing the patch.
>
>Sounds like a plan.
>
>It would probably even be easier for the bot if the reply-mail contained
>specially-formatted hints like:
>
>TEST-WITH-BELOW-PATCH: ...
>
>or so.

Since it's hard to teach ALL people about the rule, it'd be best if we
can work w/o any rules -- unless you want to be accurate&helpful or to
customize test behaviors.

Since we already tested the original patch/commit (hence the report),
we should know where the fixup should be applied to. And it'd be
reasonably easy to tell whether the fix is incremental or a
replacement -- just try git-am onto the original commit first, if
failed, continue to try the parent commit. For old bugs the fix could
be against linus/master or linux-next/master, which could be tried too.

>Btw, another nice aspect of this talking back to the bot is that before
>I, as a recipient of the bug report, go and try to prepare a guest or
>find a machine to reproduce properly, I can send a quick diff to the bot
>in the meantime and say, "try this on the guest. I have a hunch it might
>fix it."

Yes, that'd be most convenient. In general the email interface could
be something like this:

        # "key: value" fields; if you Re: to an earlier bug report, they can be auto retrieved
        compiler: gcc-6 # optional
        base-commit: v4.10-rc8 # the robot knows kernel commits from hundreds of public git trees
        ---
        the patch
        ---
        attach kconfig files

>> Yeah we have a TODO to do email based on-demand service, which looks
>> close to your proposal.
>
>Cool. Ping me if you need testers.
>
>Thanks!

Thanks,
Fengguang