"possible deadlock in console_lock_spinning_enable" and "possible deadlock in console_unlock" should be duplicate crash behaviors

[慕冬亮]

Dear kernel developers,

I found that on the syzbot dashboard, “possible deadlock in
console_lock_spinning_enable”[1] and "possible deadlock in
console_unlock"[2] should share the same root cause.

The reasons for the above statement:
1) the stack trace is the same, and this title difference is due to
the inline property of "console_lock_spinning_enable";
2) their PoCs are the same as each other;

If you can have any issues with this statement or our information is
useful to you, please let us know. Thanks very much.

[1] “possible deadlock in console_lock_spinning_enable” -
https://syzkaller.appspot.com/bug?id=2820deb61d92a8d7ab17a56ced58e963e65d76d0
[2] “possible deadlock in console_unlock” -
https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6a



--
My best regards to you.

No System Is Safe!
Dongliang Mu

[Greg KH]

Any proposed patch for these issues?

thanks,

greg k-h

[Lukas Bulwahn]

Dongliang, what is the purpose of this activity?

Why do inform the kernel maintainers that two issues share the root cause?

How does this activity contribute to fixing the bugs? Why does it
become easier to fix the issue/create a patch with the information you
provide?
(Honestly, I do not see how it does. I believe if anyone becomes
active and fixes the issue due to either one of the two reports, the
one report would be closed by the reported-by tag and the other report
would simply disappear after time because it could never be reproduced
and hence, syzbot would close it.)

Would it not be more reasonable to fix issues rather than identifying
duplicates in the automatically filled and managed database?

Best regards,

Lukas

[慕冬亮]

On Thu, Jan 21, 2021 at 8:49 PM Lukas Bulwahn <lukas....@gmail.com> wrote:
>
> On Thu, Jan 21, 2021 at 6:37 AM 慕冬亮 <mudongl...@gmail.com> wrote:
> >
> > Dear kernel developers,
> >
> > I found that on the syzbot dashboard, “possible deadlock in
> > console_lock_spinning_enable”[1] and "possible deadlock in
> > console_unlock"[2] should share the same root cause.
> >
> > The reasons for the above statement:
> > 1) the stack trace is the same, and this title difference is due to
> > the inline property of "console_lock_spinning_enable";
> > 2) their PoCs are the same as each other;
> >
> > If you can have any issues with this statement or our information is
> > useful to you, please let us know. Thanks very much.
> >
> > [1] “possible deadlock in console_lock_spinning_enable” -
> > https://syzkaller.appspot.com/bug?id=2820deb61d92a8d7ab17a56ced58e963e65d76d0
> > [2] “possible deadlock in console_unlock” -
> > https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6a
> >
> >
>
> Dongliang, what is the purpose of this activity?

Lukas,

We are conducting some research on the crash deduplication (or
identifying unique bugs) of kernel crash reports. We would like to
share some results from our research to facilitate the bugfix in the
syzbot dashboard.

>
> Why do inform the kernel maintainers that two issues share the root cause?
>
> How does this activity contribute to fixing the bugs? Why does it
> become easier to fix the issue/create a patch with the information you
> provide?

I do this for three reasons:

(1) I think the reports sharing the same root cause may expedite the
patching processing and help generate more complete patches. After
patching bugs in one case, we can close the other cases quicker.
Without these reports, one developer might be misled to develop an
incomplete patch due to a lack of understanding of the underlying bug
[1].
(2) I think it might help maintainers to better assess the severity of
the bug and thus could prioritize their effort.
(3) Multiple reports might better help maintainers diagnose the bug's
root cause.

[1] https://groups.google.com/g/syzkaller-bugs/c/9u_hEFvNbLw/m/CO9bfF8zCQAJ

> (Honestly, I do not see how it does. I believe if anyone becomes
> active and fixes the issue due to either one of the two reports, the
> one report would be closed by the reported-by tag and the other report
> would simply disappear after time because it could never be reproduced
> and hence, syzbot would close it.)
>
> Would it not be more reasonable to fix issues rather than identifying
> duplicates in the automatically filled and managed database?

Yes, fixing issues or bugs is the ultimate goal. However, crash
deduplication does benefit the bugfix process, and can reduce the
heavy burden on the kernel developers. To make our analysis more
useful, we will try our best to add some root cause analysis and how
to fix the underlying bug.

>
> Best regards,
>
> Lukas

[Lukas Bulwahn]

Well, I am not really convinced, but I guess you will convince me when
(thanks to your feature) all bugs reported by syzbot are quickly fixed
and quickly closed.

good luck :)

Lukas

[Null]

Dear kernel developers,

I found that on the syzbot dashboard, “KASAN: global-out-of-bounds Read in __xfrm6_tunnel_spi_lookup”[1], “general protection fault in __xfrm6_tunnel_spi_lookup”[2] and
“KASAN: slab-out-of-bounds Read in __xfrm6_tunnel_spi_lookup”[3] should share the same root cause.

The reasons for the above statement:

1) the stack traces are similar;
2) their PoCs are similar;
3) We extract their kernel objects related to root cause, which are similar.(xfrm6_tunnel_net
,xfrm6_tunnel_spi)

I continued Mu Dongliang's work and proposed a kernel object driven classification method.  Our new method is also conducive to the determination of root cause.

If you can have any issues with this statement or our information is useful to you, please let us know. Thanks very much.

[1] “KASAN: global-out-of-bounds Read in __xfrm6_tunnel_spi_lookup”-https://syzkaller.appspot.com/bug?id=00b1cbe14832bf7d39a13afd464e5b1da6485ce4
[2] “general protection fault in __xfrm6_tunnel_spi_lookup”-https://syzkaller.appspot.com/bug?id=d4ba8fdd2f9b47a2d1087f8368cc86b4de4eb63c
[3] “KASAN: slab-out-of-bounds Read in __xfrm6_tunnel_spi_lookup”-https://syzkaller.appspot.com/bug?id=aa3cd47728fab91e32dde562a353e64316b38c67

[Dmitry Vyukov]

On Thu, 29 Sept 2022 at 09:49, Null <zxy...@gmail.com> wrote:
>
> Dear kernel developers,
>

> I found that on the syzbot dashboard, “KASAN: global-out-of-bounds Read in __xfrm6_tunnel_spi_lookup”[1], “general protection fault in __xfrm6_tunnel_spi_lookup”[2] and
> “KASAN: slab-out-of-bounds Read in __xfrm6_tunnel_spi_lookup”[3] should share the same root cause.
>
> The reasons for the above statement:
> 1) the stack traces are similar;
> 2) their PoCs are similar;
> 3) We extract their kernel objects related to root cause, which are similar.(xfrm6_tunnel_net
> ,xfrm6_tunnel_spi)
>
> I continued Mu Dongliang's work and proposed a kernel object driven classification method. Our new method is also conducive to the determination of root cause.
>
> If you can have any issues with this statement or our information is useful to you, please let us know. Thanks very much.
>
> [1] “KASAN: global-out-of-bounds Read in __xfrm6_tunnel_spi_lookup”-https://syzkaller.appspot.com/bug?id=00b1cbe14832bf7d39a13afd464e5b1da6485ce4
> [2] “general protection fault in __xfrm6_tunnel_spi_lookup”-https://syzkaller.appspot.com/bug?id=d4ba8fdd2f9b47a2d1087f8368cc86b4de4eb63c
> [3] “KASAN: slab-out-of-bounds Read in __xfrm6_tunnel_spi_lookup”-https://syzkaller.appspot.com/bug?id=aa3cd47728fab91e32dde562a353e64316b38c67

Hi Null,

I think if these would be reported today, syzbot would automatically
merge them based on "alt titles". So this agrees with your analysis.
Alt titles are extracted from the stack traces and bug type.

> --
> 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/5a27a9ae-0fdd-4ba3-8bd5-9f99df3a6b2cn%40googlegroups.com.

[Dmitry Vyukov]

+syzkaller mailing list (please keep it in CC)

On Thu, 23 Mar 2023 at 15:48, Null <zxy...@gmail.com> wrote:
>
> Hi Dmitry Vyukov,
>
> I would like to ask you what you mean by "alt titles" and where can I see this detail? By the way, is it possible to merge the following crashes successfully by "alt titles"?
>
>
>
> [1]"KASAN: slab-out-of-bounds Write in sha512_final"-[https://syzkaller.appspot.com/bug?id=e4be30826c1b7777d69a9e3e20bc7b708ee8f82c](https://syzkaller.appspot.com/bug?id=e4be30826c1b7777d69a9e3e20bc7b708ee8f82c
>
> [2]"KASAN: slab-out-of-bounds Write in crypto_sha3_final"-[https://syzkaller.appspot.com/bug?id=84a6b6d052a9d8c9277e353dcaf7ec156d8e6ae5](https://syzkaller.appspot.com/bug?id=84a6b6d052a9d8c9277e353dcaf7ec156d8e6ae5
>
> [3]"KASAN: slab-out-of-bounds Write in sha1_finup"-[https://syzkaller.appspot.com/bug?id=4fbc4bf3d1300cf7629a7f63686b5d9cf94ed429](https://syzkaller.appspot.com/bug?id=4fbc4bf3d1300cf7629a7f63686b5d9cf94ed429
>
> [4]"KASAN: slab-out-of-bounds Write in sha1_final"-[https://syzkaller.appspot.com/bug?id=37e6f6b9b9478c41aafe5c59d33ecbecdb78da3b](https://syzkaller.appspot.com/bug?id=37e6f6b9b9478c41aafe5c59d33ecbecdb78da3b
>
> [5]"KASAN: slab-out-of-bounds Write in sha512_finup"-[https://syzkaller.appspot.com/bug?id=129e6b9bc9049c878fd3fad2a6745b8d18aa636e](https://syzkaller.appspot.com/bug?id=129e6b9bc9049c878fd3fad2a6745b8d18aa636e
>
>
>
> Our aim is to understand the boundaries of the ability of "alt titles" to classify crashes, in the hope that we can pursue more accurate classification and reduce unnecessary labor and time costs.

>
>
>
> If you can have any issues with this statement or our information is useful to you, please let us know. Thanks very much.
>
>

> Dmitry Vyukov <dvy...@google.com> 于2022年9月29日周四 16:46写道：

[Dmitry Vyukov]

On Thu, 23 Mar 2023 at 15:58, Dmitry Vyukov <dvy...@google.com> wrote:
>
> +syzkaller mailing list (please keep it in CC)
>
> On Thu, 23 Mar 2023 at 15:48, Null <zxy...@gmail.com> wrote:
> >
> > Hi Dmitry Vyukov,
> >
> > I would like to ask you what you mean by "alt titles" and where can I see this detail?

Each crash in syzkaller has a main title, but also a set of additional
titles called "alt tites".
If any of the titles for 2 crashes intersect, they are merged into the same bug.

Alt titles are added in pkg/report, search for "alt:":
https://github.com/google/syzkaller/blob/master/pkg/report/linux.go#L1292

Merging of crashes is done in the dashboard app here:
https://github.com/google/syzkaller/blob/master/dashboard/app/api.go#L727-L739

> By the way, is it possible to merge the following crashes successfully by "alt titles"?

Yes, if we assign the same alt title to all of these, they will be merged.