[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAG_fn=V+3kgtcvv5J9FZ+jf12SDVhcdwxnada=b=UuXbu+2v6Q@mail.gmail.com>
Date: Fri, 18 Jul 2025 12:09:33 +0200
From: Alexander Potapenko <glider@...gle.com>
To: 白烁冉 <baishuoran@...eu.edu.cn>
Cc: Andrey Ryabinin <ryabinin.a.a@...il.com>, Andrew Morton <akpm@...ux-foundation.org>,
Kun Hu <huk23@...udan.edu.cn>, Jiaji Qin <jjtan24@...udan.edu.cn>,
Andrey Konovalov <andreyknvl@...il.com>, Dmitry Vyukov <dvyukov@...gle.com>,
Vincenzo Frascino <vincenzo.frascino@....com>, kasan-dev@...glegroups.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: KASAN: out-of-bounds in __asan_memcpy
On Fri, Jul 18, 2025 at 11:19 AM 白烁冉 <baishuoran@...eu.edu.cn> wrote:
>
> Dear Maintainers,
>
Hi Shuoran,
Your colleague Kun Hu reported a use-after free with the same stack
trace in May: https://lkml.org/lkml/2025/5/21/611
At that time I pointed out that this bug is already well known to
syzkaller, and there is little value in reporting it again.
Note that the out-of-bounds report is also known to syzkaller:
https://syzkaller.appspot.com/bug?extid=aa6df9d3b383bf5f047f
Is there any particular reason to report the same bug over and over again?
> When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash was triggered.
Unfortunately the fact that your customized syzkaller instance found a
known bug doesn't indicate that any of your customizations work.
>
> HEAD commit: 6537cfb395f352782918d8ee7b7f10ba2cc3cbf2
> git tree: upstream
> Output: https://github.com/pghk13/Kernel-Bug/blob/main/0702_6.14/KASAN%3A%20out-of-bounds%20in%20__asan_memcpy/11_report.txt
Both this report and the stack trace below lack the file:line
information, which usually urges people to close the email.
Please refer to
https://github.com/google/syzkaller/blob/master/docs/linux/reporting_kernel_bugs.md
for some suggestions on how to give the users more information.
> The error occurs around line 105 of the function, possibly during the second kasan_check_range call, which checks the target address dest: it may be due to dest + len exceeding the allocated memory boundary, dest pointing to freed memory (use-after-free), or the len parameter being too large, causing the target address range to exceed the valid area.
This is clearly an LLM-generated description, and a poor one. There
can be potential for LLMs helping people to understand bug reports,
but when working on a prototype you'd better check every text that you
send out.
> We have reproduced this issue several times on 6.14 again.
There is no point to reproduce bugs on 6.14 as long as it is
reproducible upstream.
If it is not, the best thing you can do is probably to find out which
commit fixed it, and notify the maintainers that the commit needs to
be backported.
>
> --
> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@...glegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/kasan-dev/746aed.1562c.1981cd4e43c.Coremail.baishuoran%40hrbeu.edu.cn.
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Powered by blists - more mailing lists