Wrong cause bisection of general protection fault in __x86_indirect_thunk_rbx

[sayni...@gmail.com]

Hi,

The cause commit and patch commit of https://syzkaller.appspot.com/bug?id=9c65accb85b71ee72e58b2874fc7608a28e4d641 is the same. Although the commit id is not the same, but the code and commit message are almost the same. It seems that something is wrong with this cause bisection.

[sayni...@gmail.com]

Or the patch commit is wrong. As I the crashed kernel contains the patch code.

[Xingyu Li]

Also,https://syzkaller.appspot.com/bug?id=510646f37157a7b21558e86fc411ab2a3a30c451 its casue commit also contains the patch code. Do I miss something? It's too strange.

在 2020年5月2日星期六 UTC-7下午7:23:44，sayni...@gmail.com写道：

[Dmitry Vyukov]

On Sun, May 3, 2020 at 4:21 AM <sayni...@gmail.com> wrote:
>
> Hi,
>
> The cause commit and patch commit of https://syzkaller.appspot.com/bug?id=9c65accb85b71ee72e58b2874fc7608a28e4d641 is the same. Although the commit id is not the same, but the code and commit message are almost the same. It seems that something is wrong with this cause bisection.

Hi saynice111,

I don't understand what you are pointing at. Bisection log and result
look sane at first glance.
What is "patch commit"? What commits are you referring to? And why
should they be the same/not the same? And how that is relevant to the
bisection result.

[Dmitry Vyukov]

On Sun, May 3, 2020 at 5:48 AM Xingyu Li <lixing...@gmail.com> wrote:
>
> Also,https://syzkaller.appspot.com/bug?id=510646f37157a7b21558e86fc411ab2a3a30c451 its casue commit also contains the patch code. Do I miss something? It's too strange.

Hi Xingyu,

Please elaborate. What is wrong? What patch code?

> 在 2020年5月2日星期六 UTC-7下午7:23:44，sayni...@gmail.com写道：
>>
>> Or the patch commit is wrong. As I the crashed kernel contains the patch code.
>>
>> On Saturday, May 2, 2020 at 7:21:19 PM UTC-7, sayni...@gmail.com wrote:
>>>
>>> Hi,
>>>
>>> The cause commit and patch commit of https://syzkaller.appspot.com/bug?id=9c65accb85b71ee72e58b2874fc7608a28e4d641 is the same. Although the commit id is not the same, but the code and commit message are almost the same. It seems that something is wrong with this cause bisection.
>

> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/9dc2ee82-9a2f-42af-b0b8-5b173ace614c%40googlegroups.com.

[David Lee]

Hi,

https://syzkaller.appspot.com/bug?id=9c65accb85b71ee72e58b2874fc7608a28e4d641 says the crash commit of linux-next for this bug is d881de30d29ee4d14a475b81e523e9335f81ab9f. This is the crash commit https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/tree/fs/locks.c?id=d881de30d29ee4d14a475b81e523e9335f81ab9f. But the line 430 of this file shows it's already patched according to the patch https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6367d6241371566597c9ab6efe4de0abf254eed showed in syzbot

[Dmitry Vyukov]

On Sun, May 3, 2020 at 10:00 PM David Lee <sayni...@gmail.com> wrote:
>
> Hi,
> https://syzkaller.appspot.com/bug?id=9c65accb85b71ee72e58b2874fc7608a28e4d641 says the crash commit of linux-next for this bug is d881de30d29ee4d14a475b81e523e9335f81ab9f. This is the crash commit https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/tree/fs/locks.c?id=d881de30d29ee4d14a475b81e523e9335f81ab9f. But the line 430 of this file shows it's already patched according to the patch https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6367d6241371566597c9ab6efe4de0abf254eed showed in syzbot

I think that's because of linux-next where commits are not stable.
Commit title may be the same, but commit contents may be different.

> On Sunday, May 3, 2020 at 3:24:18 AM UTC-7, Dmitry Vyukov wrote:
>>
>> On Sun, May 3, 2020 at 4:21 AM <sayni...@gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > The cause commit and patch commit of https://syzkaller.appspot.com/bug?id=9c65accb85b71ee72e58b2874fc7608a28e4d641 is the same. Although the commit id is not the same, but the code and commit message are almost the same. It seems that something is wrong with this cause bisection.
>>
>> Hi saynice111,
>>
>> I don't understand what you are pointing at. Bisection log and result
>> look sane at first glance.
>> What is "patch commit"? What commits are you referring to? And why
>> should they be the same/not the same? And how that is relevant to the
>> bisection result.
>

> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/0c3471c7-dcd6-4cfd-b134-813b92d82ad9%40googlegroups.com.

[Dmitry Vyukov]

On Mon, May 4, 2020 at 12:45 PM Dmitry Vyukov <dvy...@google.com> wrote:
> > Hi,
> > https://syzkaller.appspot.com/bug?id=9c65accb85b71ee72e58b2874fc7608a28e4d641 says the crash commit of linux-next for this bug is d881de30d29ee4d14a475b81e523e9335f81ab9f. This is the crash commit https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/tree/fs/locks.c?id=d881de30d29ee4d14a475b81e523e9335f81ab9f. But the line 430 of this file shows it's already patched according to the patch https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6367d6241371566597c9ab6efe4de0abf254eed showed in syzbot
>
> I think that's because of linux-next where commits are not stable.
> Commit title may be the same, but commit contents may be different.

If you rebase commits, you may introduce and fix a bug with commits
with the same title.

[David Lee]

Commit title? A little confused. Here, the commit title is not different. d881de30d29ee4d14a475b81e523e9335f81ab9f and d6367d6241371566597c9ab6efe4de0abf254eed have different title.

> To unsubscribe from this group and stop receiving emails from it, send an email to syzk...@googlegroups.com.

[Dmitry Vyukov]

On Wed, May 6, 2020 at 8:31 AM David Lee <sayni...@gmail.com> wrote:
>
> Commit title? A little confused. Here, the commit title is not different. d881de30d29ee4d14a475b81e523e9335f81ab9f and d6367d6241371566597c9ab6efe4de0abf254eed have different title.

I guess I mixed up things because we started discussing 2 different
things in the same email thread. It's the other one here is about the
same commit title, right?

For this one maybe somebody marked a bug with a wrong fixing commit then?

> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/dce1c581-2fb8-4f94-921b-58fbcf1eaab1%40googlegroups.com.

[David Lee]

So there are two questions in this thread.

1)the  cause commit and patch commit of https://syzkaller.appspot.com/bug?id=9c65accb85b71ee72e58b2874fc7608a28e4d641 are dee160df820de41ff2f59a715643680822a0ab06 and d6367d6241371566597c9ab6efe4de0abf254eed . Although commit id of these two are different, their title  and contents are the same ( I checked). As https://groups.google.com/forum/#!msg/syzkaller-bugs/yZhQdmRGlVo/_T57iJ4AAwAJ said, dee160df820de41ff2f59a715643680822a0ab06 is not made into mainline and replaced by 6367d624137. My question is why syzbot recognize the same commit(except the commit id) both as the cause commit and the patch commit. Then I found https://syzkaller.appspot.com/bug?id=9c65accb85b71ee72e58b2874fc7608a28e4d641 said the log of the cause commit is general protection fault in locks_remove_flock, not the same bug as this bug. So only there is a crash in the process of finding cause commit, syzbot thought it's the cause commit and did not check if the crash is the same. If so, this quesion is voled. By the way, as you showed in another thread of my question, unrelated crashes is one reason why the success rate of cause bisection is low.

2)the crash commit of  https://syzkaller.appspot.com/bug?id=9c65accb85b71ee72e58b2874fc7608a28e4d641 is d881de30d29ee4d14a475b81e523e9335f81ab9f, but I found that this commit in linux-next also contains the patch code. My quesion is why the code of crash commit also contains the patch code. You said that somebody marked a bug with a wrong fixing commit. But this bug is found by syzbot(https://groups.google.com/forum/#!msg/syzkaller-bugs/yZhQdmRGlVo/1YCseKUUAAAJ). I thought syzbot must test the PoC serval times. Only the kernel crashes at every time, syzbot thinks it as a bug and reports it. So syzbot will give wrong report? Besides, for such bug, which the crash commit is wrong, how should I reproduce it? 

> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/dce1c581-2fb8-4f94-921b-58fbcf1eaab1%40googlegroups.com.

[Dmitry Vyukov]

On Wed, May 6, 2020 at 10:55 PM David Lee <sayni...@gmail.com> wrote:
>
> So there are two questions in this thread.
> 1)the cause commit and patch commit of https://syzkaller.appspot.com/bug?id=9c65accb85b71ee72e58b2874fc7608a28e4d641 are dee160df820de41ff2f59a715643680822a0ab06 and d6367d6241371566597c9ab6efe4de0abf254eed . Although commit id of these two are different, their title and contents are the same ( I checked). As https://groups.google.com/forum/#!msg/syzkaller-bugs/yZhQdmRGlVo/_T57iJ4AAwAJ said, dee160df820de41ff2f59a715643680822a0ab06 is not made into mainline and replaced by 6367d624137. My question is why syzbot recognize the same commit(except the commit id) both as the cause commit and the patch commit.

syzbot does not recognize/detect fixing commits. It has been told that
that commit fixes the bug. So the questions regarding the fixing
commit should go to the human who said that that commit fixes the bug.

> Then I found https://syzkaller.appspot.com/bug?id=9c65accb85b71ee72e58b2874fc7608a28e4d641 said the log of the cause commit is general protection fault in locks_remove_flock, not the same bug as this bug. So only there is a crash in the process of finding cause commit, syzbot thought it's the cause commit and did not check if the crash is the same. If so, this quesion is voled. By the way, as you showed in another thread of my question, unrelated crashes is one reason why the success rate of cause bisection is low.

It is not possible to understand if the crash is the same or not. And
if we could, it's not something we could rely on. If you see a
different crash, you don't know if the original crash is also present
or not. The fact that there is another bug, does not give any
information about the presence of the original bug. So any unrelated
bugs with inherently diverge and break bisection.
syzkaller uses a simple binary predicate: crashed/not crashed.

> 2)the crash commit of https://syzkaller.appspot.com/bug?id=9c65accb85b71ee72e58b2874fc7608a28e4d641 is d881de30d29ee4d14a475b81e523e9335f81ab9f, but I found that this commit in linux-next also contains the patch code. My quesion is why the code of crash commit also contains the patch code. You said that somebody marked a bug with a wrong fixing commit.

Yes. I said it _may_ be marked with a wrong commit.

> But this bug is found by syzbot(https://groups.google.com/forum/#!msg/syzkaller-bugs/yZhQdmRGlVo/1YCseKUUAAAJ). I thought syzbot must test the PoC serval times.

Not. Not possible as well.

> Only the kernel crashes at every time, syzbot thinks it as a bug and reports it.

No.

> So syzbot will give wrong report?

I don't understand what you mean by "wrong". It merely communicates
what happened in reality. It does not invent anything or hypothesise.
In this sense all reports are true.

> Besides, for such bug, which the crash commit is wrong, how should I reproduce it?

The crash commit is always correct. That crash happened on that
commit, there is no doubt here.

> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/0a60451a-411c-44a3-b935-6c4d24a05be1%40googlegroups.com.

[David Lee]

Thanks for your reply. Very helpful for me.

> It is not possible to understand if the crash is the same or not.

I can not understand why it's not possible. From my understanding, we can extract call trace, bug title from crash log to determine if it's the same crash.

> Yes. I said it _may_ be marked with a wrong commit.

> The crash commit is always correct. That crash happened on that

commit, there is no doubt here.

I thought the the crash commit is marked automatically and should not go wrong?

But PoC can not work on the crash commit for this bug. So how should I reproduce this bug?

> Not. Not possible as well.

So once the kernel crash one time, syzbot see it as a bug and report. Also I can not understand why it's not possible to run a PoC serval times to confirm the existence of the bug.

Thanks again. It's really helpful for me.

> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/0a60451a-411c-44a3-b935-6c4d24a05be1%40googlegroups.com.

[Dmitry Vyukov]

On Thu, May 7, 2020 at 9:42 AM David Lee <sayni...@gmail.com> wrote:
>
> Thanks for your reply. Very helpful for me.
>
> > It is not possible to understand if the crash is the same or not.
>
> I can not understand why it's not possible. From my understanding, we can extract call trace, bug title from crash log to determine if it's the same crash.

A number of reasons, most notably:
- a single bug may result in different manifestations
- a function may be renamed/stack change across revisions

But either way, see the next sentence. It will not allow you to do
what you think it will allow you to do.

> > Yes. I said it _may_ be marked with a wrong commit.
> > The crash commit is always correct. That crash happened on that
> commit, there is no doubt here.
>
> I thought the the crash commit is marked automatically and should not go wrong?
> But PoC can not work on the crash commit for this bug. So how should I reproduce this bug?

Crash commit is provided by syzbot and is correct.
Fixing commit provided by a human. syzbot logic has nothing to do with it.

> > Not. Not possible as well.
>
> So once the kernel crash one time, syzbot see it as a bug and report. Also I can not understand why it's not possible to run a PoC serval times to confirm the existence of the bug.

It crashed already. So the bug exists.
Lots of bugs don't reproduce always.

> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/22453773-9f37-4fa9-9107-4a00ca8de05f%40googlegroups.com.