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:   Thu, 28 Jul 2022 16:10:25 +0200
From:   Lukas Bulwahn <lukas.bulwahn@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Dipanjan Das <mail.dipanjan.das@...il.com>,
        David Howells <dhowells@...hat.com>,
        Sasha Levin <sashal@...nel.org>, fmdefrancesco@...il.com,
        Eric Dumazet <edumazet@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        syzkaller <syzkaller@...glegroups.com>,
        fleischermarius@...glemail.com, its.priyanka.bose@...il.com
Subject: Re: KASAN: use-after-free Read in post_one_notification

On Thu, Jul 28, 2022 at 8:52 AM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Wed, Jul 27, 2022 at 02:28:45PM -0700, Dipanjan Das wrote:
> > Hi,
> >
> > We would like to report the following bug which has been found by our
> > modified version of syzkaller.
> >
> > ======================================================
> > description: KASAN: use-after-free Read in post_one_notification
> > affected file: kernel/watch_queue.c
> > kernel version: 5.10.131
> > kernel commit: 8f95261a006489c828f1d909355669875649668b
> > git tree: upstream
> > kernel config: https://syzkaller.appspot.com/x/.config?x=e49433cfed49b7d9
> > crash reproducer: attached
> > patch: This bug was previously reported by syzkaller for kernel
> > version 5.17. The same patch works for kernel version 5.10 as well,
> > i.e., we tested that the repro can no longer triggers the reported
> > crash with this patch:
> > https://syzkaller.appspot.com/text?tag=Patch&x=13b8c83c080000
>
> I'm sorry, I do not understand.  So this is fixed in Linus's tree?  But
> not in 5.10.y?  Or it is not fixed everywhere?
>
> If it is fixed, what is the git commit id of the patch in Linus's tree
> that fixes this that should be backported to 5.10.y?
>
> confused,
>

I will try to help our poor confused kernel maintainers here with some
quick background information I could quickly find (just out of
curiosity on what these reports are all about...). Maybe, next time,
the bug reporters can do that simple and basic investigation before
reporting, and provide that information in a condensed form and at the
right point in time, so Greg or Sasha can really act upon that.

For the syzkaller-found KASAN bug report above, there is a patch in
discussion (https://lore.kernel.org/lkml/182407602ce.190e58816827.7904364186178466266@siddh.me/)
to resolve the issue in mainline. As of writing, the author still
intends to provide a proper working v3 patch, which then might be
applied by David Howells. So far, this patch has not been in
linux-next, nor even Linus Torvalds' tree (mainline). The reporters in
this email suggest that this patch once it reaches mainline can be
backported to the 5.10 stable branch to resolve an existing
syzkaller-triggered bug in the v5.10 versions.

Dipanjan, are you aware of the preferred options to work with stable
maintainers mentioned in
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html?
Please read that page if you have not done that yet.

Dipanjan, could you please follow and influence the development and
handling of the patch above?

Either, you can achieve that the patch is already prepared properly,
so that it is picked up to stable due to the meta-information in the
patch commit message (Option 1 in the stable-kernel-rules, preferred).
Or, after the patch has been merged to Linus’ tree, send an email to
stable@...r.kernel.org containing the subject of the patch, the commit
ID, why you think it should be applied, and what kernel version you
wish it to be applied to (Option 2 in stable-kernel-rules, if Option 1
is not successful).

I believe that this above is a good way (maybe even the best way) to
interact with the kernel community and its stable maintainers and get
the issues resolved that you are reporting.


I hope this helps,

Lukas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ