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

[Ingo Molnar]

* 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

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