Re: [PATCH v4] mm, kasan, kmsan: copy_from/to_kernel_nofault

[Sabyrzhan Tasbolatov]

On Wed, Oct 9, 2024 at 12:34 AM Marco Elver <elver@xxxxxxxxxx> wrote:
>
> On Tue, 8 Oct 2024 at 21:28, Sabyrzhan Tasbolatov <snovitoll@xxxxxxxxx> wrote:
> >
> > Instrument copy_from_kernel_nofault() with KMSAN for uninitialized kernel
> > memory check and copy_to_kernel_nofault() with KASAN, KCSAN to detect
> > the memory corruption.
> >
> > syzbot reported that bpf_probe_read_kernel() kernel helper triggered
> > KASAN report via kasan_check_range() which is not the expected behaviour
> > as copy_from_kernel_nofault() is meant to be a non-faulting helper.
> >
> > Solution is, suggested by Marco Elver, to replace KASAN, KCSAN check in
> > copy_from_kernel_nofault() with KMSAN detection of copying uninitilaized
> > kernel memory. In copy_to_kernel_nofault() we can retain
> > instrument_write() explicitly for the memory corruption instrumentation.
> >
> > copy_to_kernel_nofault() is tested on x86_64 and arm64 with
> > CONFIG_KASAN_SW_TAGS. On arm64 with CONFIG_KASAN_HW_TAGS,
> > kunit test currently fails. Need more clarification on it
> > - currently, disabled in kunit test.
> >
> > Link: https://lore.kernel.org/linux-mm/CANpmjNMAVFzqnCZhEity9cjiqQ9CVN1X7qeeeAp_6yKjwKo8iw@xxxxxxxxxxxxxx/
> > Reviewed-by: Marco Elver <elver@xxxxxxxxxx>
> > Reported-by: syzbot+61123a5daeb9f7454599@xxxxxxxxxxxxxxxxxxxxxxxxx
> > Closes: https://syzkaller.appspot.com/bug?extid=61123a5daeb9f7454599
> > Reported-by: Andrey Konovalov <andreyknvl@xxxxxxxxx>
> > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=210505
> > Signed-off-by: Sabyrzhan Tasbolatov <snovitoll@xxxxxxxxx>
> > ---
> > v2:
> > - squashed previous submitted in -mm tree 2 patches based on Linus tree
> > v3:
> > - moved checks to *_nofault_loop macros per Marco's comments
> > - edited the commit message
> > v4:
> > - replaced Suggested-By with Reviewed-By: Marco Elver
>
> For future reference: No need to send v+1 just for this tag. Usually
> maintainers pick up tags from the last round without the original
> author having to send out a v+1 with the tags. Of course, if you make
> other corrections and need to send a v+1, then it is appropriate to
> collect tags where those tags would remain valid (such as on unchanged
> patches part of the series, or for simpler corrections).

Thanks! Will do it next time.

Please advise if Andrew should need to be notified in the separate cover letter
to remove the prev. merged  to -mm tree patch and use this v4:
https://lore.kernel.org/all/20241008020150.4795AC4CEC6@xxxxxxxxxxxxxxx/