From: Hillf Danton <hdanton@sina.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: syzbot <syzbot+f625baafb9a1c4bfc3f6@syzkaller.appspotmail.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org,
syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Subject: Re: general protection fault in mm_update_next_owner
Date: Sun, 24 Oct 2021 13:25:14 +0800 [thread overview]
Message-ID: <20211024052514.1236-1-hdanton@sina.com> (raw)
In-Reply-To: <CACT4Y+btAivG8iYQFM=Qy_qMoE0SFNhx-ngjN=1hgf7UGrNViw@mail.gmail.com>
On Tue, 11 Jun 2019 09:00:09 +0200 Dmitry Vyukov wrote:
>On Mon, Jun 10, 2019 at 11:27 PM Eric W. Biederman wrote:
>>
>> syzbot <syzbot+f625baafb9a1c4bfc3f6@syzkaller.appspotmail.com> writes:
>>
>> > syzbot has bisected this bug to:
>> >
>> > commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
>> > Author: John Fastabend <john.fastabend@gmail.com>
>> > Date: Sat Jun 30 13:17:47 2018 +0000
>> >
>> > bpf: sockhash fix omitted bucket lock in sock_close
>> >
>> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15e978e1a00000
>> > start commit: 38e406f6 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
>> > git tree: net
>> > final crash: https://syzkaller.appspot.com/x/report.txt?x=17e978e1a00000
>> > console output: https://syzkaller.appspot.com/x/log.txt?x=13e978e1a00000
>> > kernel config: https://syzkaller.appspot.com/x/.config?x=60564cb52ab29d5b
>> > dashboard link: https://syzkaller.appspot.com/bug?extid=f625baafb9a1c4bfc3f6
>> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1193d81ea00000
>> >
>> > Reported-by: syzbot+f625baafb9a1c4bfc3f6@syzkaller.appspotmail.com
>> > Fixes: e9db4ef6bf4c ("bpf: sockhash fix omitted bucket lock in sock_close")
>> >
>> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>>
>> How is mm_update_next_owner connected to bpf?
>
>
>There seems to be a nasty bug in bpf that causes assorted crashes
>throughout the kernel for some time. I've seen a bunch of reproducers
>that do something with bpf and then cause a random crash. The more
>unpleasant ones are the bugs without reproducers, because for these we
>don't have a way to link them back to the bpf bug but they are still
>hanging there without good explanation, e.g. maybe a part of one-off
>crashes in moderation:
>https://syzkaller.appspot.com/upstream#moderation2
>
>Such bugs are nice to fix asap to not produce more and more random
>crash reports.
>
>Hillf, did you understand the mechanics of this bug and memory
>corruption? A good question is why this was unnoticed by KASAN. If we
>could make it catch it at the point of occurrence, then it would be a
>single bug report clearly attributed to bpf rather then dozens of
>assorted crashes.
Sorry for reading this message at lore today and late reply because it
did not land in my inbox in Jun 2019.
A couple of days ago, I saw an offline linux-4.18 page fault Oops report
that could trigger the check for X86_PF_USER and X86_PF_INSTR added in
03c81ea33316 ("x86/fault: Improve kernel-executing-user-memory handling")
and given the reported CPU is Intel Atom, any light on how to reproduce
it is highly appreciated.
Hillf
parent reply other threads:[~2021-10-24 5:25 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <CACT4Y+btAivG8iYQFM=Qy_qMoE0SFNhx-ngjN=1hgf7UGrNViw@mail.gmail.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211024052514.1236-1-hdanton@sina.com \
--to=hdanton@sina.com \
--cc=dvyukov@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=syzbot+f625baafb9a1c4bfc3f6@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox