Re: [lkp] [string] 5f6f0801f5: BUG: KASan: out of bounds access in strlcpy+0xc8/0x250 at addr ffff88011a666ee0

From: Ingo Molnar
Date: Mon Oct 12 2015 - 03:34:08 EST



* kernel test robot <ying.huang@xxxxxxxxxxxxxxx> wrote:

> FYI, we noticed the below changes on
>
> git://internal_mailing_list_patch_tree Ingo-Molnar/string-Improve-the-generic-strlcpy-implementation
> commit 5f6f0801f5fdfce4984c6a14f99dbfbb417acb66 ("string: Improve the generic strlcpy() implementation")

Hm, there's no such commit ID anywhere I can see - did you rebase my tree perhaps?

I am guessing that you rebased the attached WIP commit I have in -tip (not
permanently committed), which bases strlcpy() off strscpy() and through which
strscpy() gains a couple of hundred usage sites:

+size_t strlcpy(char *dst, const char *src, size_t dst_size)
+{
+ int ret = strscpy(dst, src, dst_size);
+
+ /* Handle the insane and broken strlcpy() overflow return value: */
+ if (ret < 0)
+ return dst_size + strlen(src+dst_size);
+
+ return ret;
+}
+EXPORT_SYMBOL(strlcpy);

Now depending on what tree you tested it on, this KASAN report might either be a
known and meanwhile strscpy() bug - or might perhaps be something new!

The old, known fix is:

990486c8af04 strscpy: zero any trailing garbage bytes in the destination

> [ 22.205482] systemd[1]: RTC configured in localtime, applying delta of 480 minutes to system time.
> [ 22.214569] random: systemd urandom read with 11 bits of entropy available
> [ 22.241378] ==================================================================
> [ 22.242067] BUG: KASan: out of bounds access in strlcpy+0xc8/0x250 at addr ffff88011a666ee0
> [ 22.242067] Read of size 8 by task systemd/1
> [ 22.242067] =============================================================================
> [ 22.242067] BUG kmalloc-64 (Not tainted): kasan: bad access detected
> [ 22.242067] -----------------------------------------------------------------------------
> [ 22.242067]
> [ 22.242067] Disabling lock debugging due to kernel taint
> [ 22.242067] INFO: Slab 0xffffea0004699980 objects=64 used=64 fp=0x (null) flags=0x200000000000080
> [ 22.242067] INFO: Object 0xffff88011a666ec0 @offset=3776 fp=0x7379732f62696c2f
> [ 22.242067]
> [ 22.242067] Bytes b4 ffff88011a666eb0: 00 00 00 00 00 00 00 00 a7 4b c2 ef 07 00 00 00 .........K......
> [ 22.242067] Object ffff88011a666ec0: 2f 6c 69 62 2f 73 79 73 74 65 6d 64 2f 73 79 73 /lib/systemd/sys

Is there any stack trace of this bad access?

The lack of stack trace and the unknown commit ID make it really hard to analyze
this bug.

Thanks,

Ingo

====================>