Re: [lkp-robot] [printk] 7f7c60e066: BUG:KASAN:slab-out-of-bounds

[Kees Cook]

On Mon, Oct 30, 2017 at 7:39 PM, Tobin C. Harding  wrote:
> On Mon, Oct 30, 2017 at 05:14:59PM -0700, Kees Cook wrote:
>> On Wed, Oct 25, 2017 at 9:22 AM, kernel test robot
>>  wrote:
>
> thanks for looking at this, I was at a loss as to what (if any) action I
> needed to take.

I have finally learned after several instances that if 0day produces a
report, it's real. :) Even the crazy stuff I haven't been able to
reproduce on my own has come back to bite me later, so now I'm very
attentive to 0day report. ;)

>> > FYI, we noticed the following commit (built with gcc-4.9):
>> >
>> > commit: 7f7c60e0663645e757e520245606fde9c6e326bb ("printk: hash addresses 
>> > printed with %p")
>> > url: 
>> > https://github.com/0day-ci/linux/commits/Tobin-C-Harding/printk-hash-addresses-printed-with-p/20171024-231922
>>
>> It's not clear to me which of the various versions this test ran
>> against, but it seems like the printf self-tests got very confused by
>> the results:
>>
>> > [   40.275423] test_printf: kvasprintf(..., "%p %p", ...) returned 
>> > '3cf9adbe eff717bf', expected '01234567 fedcba98'
>> > [   40.296739] test_printf: vsnprintf(buf, 256, "|%-*p|%*p|", ...) 
>> > returned 19, expected 39
>> > [   40.322776] test_printf: vsnprintf(buf, 16, "|%-*p|%*p|", ...) returned 
>> > 19, expected 39
>> > [   40.334834] test_printf: vsnprintf(buf, 0, "|%-*p|%*p|", ...) returned 
>> > 19, expected 39
>>
>> I assume v10 will fix the width issues, but probably not the value tests...
>
> Oh, so I need to update lib/test_printf.c to cover hashed %p.

Yeah, looks like it.

>> And it claims a use-after-free, too:
>>
>> > [   39.757461] The buggy address belongs to the object at 22cb34bb
>> > [   39.757461]  which belongs to the cache kmalloc-32 of size 32
>> > [   39.757461] The buggy address is located 0 bytes inside of
>> > [   39.757461]  32-byte region [22cb34bb, 24ac3a60)
>>
>> Which becomes rather unreadable, since the address got hashed. :P
>
> So I think we need to patch mm/kasan/report to use %pK instead of %p.

Yeah, looks like it.

> I don't know what I should be doing about
>
> [   39.757461] BUG: KASAN: slab-out-of-bounds in __test+0xee/0x13f

Yeah, I have no idea where this error came from. It does seem
triggered by the printf self-test code, though, so if a KASAN bulid
doesn't show it, maybe a full SLAB DEBUG build will?

-Kees

-- 
Kees Cook
Pixel Security

Re: [lkp-robot] [printk] 7f7c60e066: BUG:KASAN:slab-out-of-bounds

[Kees Cook]

On Mon, Oct 30, 2017 at 7:39 PM, Tobin C. Harding  wrote:
> On Mon, Oct 30, 2017 at 05:14:59PM -0700, Kees Cook wrote:
>> On Wed, Oct 25, 2017 at 9:22 AM, kernel test robot
>>  wrote:
>
> thanks for looking at this, I was at a loss as to what (if any) action I
> needed to take.

I have finally learned after several instances that if 0day produces a
report, it's real. :) Even the crazy stuff I haven't been able to
reproduce on my own has come back to bite me later, so now I'm very
attentive to 0day report. ;)

>> > FYI, we noticed the following commit (built with gcc-4.9):
>> >
>> > commit: 7f7c60e0663645e757e520245606fde9c6e326bb ("printk: hash addresses 
>> > printed with %p")
>> > url: 
>> > https://github.com/0day-ci/linux/commits/Tobin-C-Harding/printk-hash-addresses-printed-with-p/20171024-231922
>>
>> It's not clear to me which of the various versions this test ran
>> against, but it seems like the printf self-tests got very confused by
>> the results:
>>
>> > [   40.275423] test_printf: kvasprintf(..., "%p %p", ...) returned 
>> > '3cf9adbe eff717bf', expected '01234567 fedcba98'
>> > [   40.296739] test_printf: vsnprintf(buf, 256, "|%-*p|%*p|", ...) 
>> > returned 19, expected 39
>> > [   40.322776] test_printf: vsnprintf(buf, 16, "|%-*p|%*p|", ...) returned 
>> > 19, expected 39
>> > [   40.334834] test_printf: vsnprintf(buf, 0, "|%-*p|%*p|", ...) returned 
>> > 19, expected 39
>>
>> I assume v10 will fix the width issues, but probably not the value tests...
>
> Oh, so I need to update lib/test_printf.c to cover hashed %p.

Yeah, looks like it.

>> And it claims a use-after-free, too:
>>
>> > [   39.757461] The buggy address belongs to the object at 22cb34bb
>> > [   39.757461]  which belongs to the cache kmalloc-32 of size 32
>> > [   39.757461] The buggy address is located 0 bytes inside of
>> > [   39.757461]  32-byte region [22cb34bb, 24ac3a60)
>>
>> Which becomes rather unreadable, since the address got hashed. :P
>
> So I think we need to patch mm/kasan/report to use %pK instead of %p.

Yeah, looks like it.

> I don't know what I should be doing about
>
> [   39.757461] BUG: KASAN: slab-out-of-bounds in __test+0xee/0x13f

Yeah, I have no idea where this error came from. It does seem
triggered by the printf self-test code, though, so if a KASAN bulid
doesn't show it, maybe a full SLAB DEBUG build will?

-Kees

-- 
Kees Cook
Pixel Security

Re: [lkp-robot] [printk] 7f7c60e066: BUG:KASAN:slab-out-of-bounds

[Tobin C. Harding]

On Mon, Oct 30, 2017 at 05:14:59PM -0700, Kees Cook wrote:
> On Wed, Oct 25, 2017 at 9:22 AM, kernel test robot
>  wrote:

thanks for looking at this, I was at a loss as to what (if any) action I
needed to take.

> > FYI, we noticed the following commit (built with gcc-4.9):
> >
> > commit: 7f7c60e0663645e757e520245606fde9c6e326bb ("printk: hash addresses 
> > printed with %p")
> > url: 
> > https://github.com/0day-ci/linux/commits/Tobin-C-Harding/printk-hash-addresses-printed-with-p/20171024-231922
> 
> It's not clear to me which of the various versions this test ran
> against, but it seems like the printf self-tests got very confused by
> the results:
> 
> > [   40.275423] test_printf: kvasprintf(..., "%p %p", ...) returned 
> > '3cf9adbe eff717bf', expected '01234567 fedcba98'
> > [   40.296739] test_printf: vsnprintf(buf, 256, "|%-*p|%*p|", ...) returned 
> > 19, expected 39
> > [   40.322776] test_printf: vsnprintf(buf, 16, "|%-*p|%*p|", ...) returned 
> > 19, expected 39
> > [   40.334834] test_printf: vsnprintf(buf, 0, "|%-*p|%*p|", ...) returned 
> > 19, expected 39
> 
> I assume v10 will fix the width issues, but probably not the value tests...

Oh, so I need to update lib/test_printf.c to cover hashed %p.

> And it claims a use-after-free, too:
> 
> > [   39.757461] The buggy address belongs to the object at 22cb34bb
> > [   39.757461]  which belongs to the cache kmalloc-32 of size 32
> > [   39.757461] The buggy address is located 0 bytes inside of
> > [   39.757461]  32-byte region [22cb34bb, 24ac3a60)
> 
> Which becomes rather unreadable, since the address got hashed. :P

So I think we need to patch mm/kasan/report to use %pK instead of %p.

I don't know what I should be doing about

[   39.757461] BUG: KASAN: slab-out-of-bounds in __test+0xee/0x13f

Awesome, thanks,
Tobin.

Re: [lkp-robot] [printk] 7f7c60e066: BUG:KASAN:slab-out-of-bounds

[Tobin C. Harding]

On Mon, Oct 30, 2017 at 05:14:59PM -0700, Kees Cook wrote:
> On Wed, Oct 25, 2017 at 9:22 AM, kernel test robot
>  wrote:

thanks for looking at this, I was at a loss as to what (if any) action I
needed to take.

> > FYI, we noticed the following commit (built with gcc-4.9):
> >
> > commit: 7f7c60e0663645e757e520245606fde9c6e326bb ("printk: hash addresses 
> > printed with %p")
> > url: 
> > https://github.com/0day-ci/linux/commits/Tobin-C-Harding/printk-hash-addresses-printed-with-p/20171024-231922
> 
> It's not clear to me which of the various versions this test ran
> against, but it seems like the printf self-tests got very confused by
> the results:
> 
> > [   40.275423] test_printf: kvasprintf(..., "%p %p", ...) returned 
> > '3cf9adbe eff717bf', expected '01234567 fedcba98'
> > [   40.296739] test_printf: vsnprintf(buf, 256, "|%-*p|%*p|", ...) returned 
> > 19, expected 39
> > [   40.322776] test_printf: vsnprintf(buf, 16, "|%-*p|%*p|", ...) returned 
> > 19, expected 39
> > [   40.334834] test_printf: vsnprintf(buf, 0, "|%-*p|%*p|", ...) returned 
> > 19, expected 39
> 
> I assume v10 will fix the width issues, but probably not the value tests...

Oh, so I need to update lib/test_printf.c to cover hashed %p.

> And it claims a use-after-free, too:
> 
> > [   39.757461] The buggy address belongs to the object at 22cb34bb
> > [   39.757461]  which belongs to the cache kmalloc-32 of size 32
> > [   39.757461] The buggy address is located 0 bytes inside of
> > [   39.757461]  32-byte region [22cb34bb, 24ac3a60)
> 
> Which becomes rather unreadable, since the address got hashed. :P

So I think we need to patch mm/kasan/report to use %pK instead of %p.

I don't know what I should be doing about

[   39.757461] BUG: KASAN: slab-out-of-bounds in __test+0xee/0x13f

Awesome, thanks,
Tobin.

Re: [lkp-robot] [printk] 7f7c60e066: BUG:KASAN:slab-out-of-bounds

[Ye Xiaolong]

On 10/30, Kees Cook wrote:
>On Wed, Oct 25, 2017 at 9:22 AM, kernel test robot
> wrote:
>>
>> FYI, we noticed the following commit (built with gcc-4.9):
>>
>> commit: 7f7c60e0663645e757e520245606fde9c6e326bb ("printk: hash addresses 
>> printed with %p")
>> url: 
>> https://github.com/0day-ci/linux/commits/Tobin-C-Harding/printk-hash-addresses-printed-with-p/20171024-231922
>
>It's not clear to me which of the various versions this test ran

We'll improve it by showing the version info for LKML patchset.

Thanks,
Xiaolong

>against, but it seems like the printf self-tests got very confused by
>the results:
>
>> [   40.275423] test_printf: kvasprintf(..., "%p %p", ...) returned '3cf9adbe 
>> eff717bf', expected '01234567 fedcba98'
>> [   40.296739] test_printf: vsnprintf(buf, 256, "|%-*p|%*p|", ...) returned 
>> 19, expected 39
>> [   40.322776] test_printf: vsnprintf(buf, 16, "|%-*p|%*p|", ...) returned 
>> 19, expected 39
>> [   40.334834] test_printf: vsnprintf(buf, 0, "|%-*p|%*p|", ...) returned 
>> 19, expected 39
>
>I assume v10 will fix the width issues, but probably not the value tests...
>
>And it claims a use-after-free, too:
>
>> [   39.757461] The buggy address belongs to the object at 22cb34bb
>> [   39.757461]  which belongs to the cache kmalloc-32 of size 32
>> [   39.757461] The buggy address is located 0 bytes inside of
>> [   39.757461]  32-byte region [22cb34bb, 24ac3a60)
>
>Which becomes rather unreadable, since the address got hashed. :P
>
>-Kees
>
>-- 
>Kees Cook
>Pixel Security

Re: [lkp-robot] [printk] 7f7c60e066: BUG:KASAN:slab-out-of-bounds

[Ye Xiaolong]

On 10/30, Kees Cook wrote:
>On Wed, Oct 25, 2017 at 9:22 AM, kernel test robot
> wrote:
>>
>> FYI, we noticed the following commit (built with gcc-4.9):
>>
>> commit: 7f7c60e0663645e757e520245606fde9c6e326bb ("printk: hash addresses 
>> printed with %p")
>> url: 
>> https://github.com/0day-ci/linux/commits/Tobin-C-Harding/printk-hash-addresses-printed-with-p/20171024-231922
>
>It's not clear to me which of the various versions this test ran

We'll improve it by showing the version info for LKML patchset.

Thanks,
Xiaolong

>against, but it seems like the printf self-tests got very confused by
>the results:
>
>> [   40.275423] test_printf: kvasprintf(..., "%p %p", ...) returned '3cf9adbe 
>> eff717bf', expected '01234567 fedcba98'
>> [   40.296739] test_printf: vsnprintf(buf, 256, "|%-*p|%*p|", ...) returned 
>> 19, expected 39
>> [   40.322776] test_printf: vsnprintf(buf, 16, "|%-*p|%*p|", ...) returned 
>> 19, expected 39
>> [   40.334834] test_printf: vsnprintf(buf, 0, "|%-*p|%*p|", ...) returned 
>> 19, expected 39
>
>I assume v10 will fix the width issues, but probably not the value tests...
>
>And it claims a use-after-free, too:
>
>> [   39.757461] The buggy address belongs to the object at 22cb34bb
>> [   39.757461]  which belongs to the cache kmalloc-32 of size 32
>> [   39.757461] The buggy address is located 0 bytes inside of
>> [   39.757461]  32-byte region [22cb34bb, 24ac3a60)
>
>Which becomes rather unreadable, since the address got hashed. :P
>
>-Kees
>
>-- 
>Kees Cook
>Pixel Security

Re: [lkp-robot] [printk] 7f7c60e066: BUG:KASAN:slab-out-of-bounds

[Kees Cook]

On Wed, Oct 25, 2017 at 9:22 AM, kernel test robot
 wrote:
>
> FYI, we noticed the following commit (built with gcc-4.9):
>
> commit: 7f7c60e0663645e757e520245606fde9c6e326bb ("printk: hash addresses 
> printed with %p")
> url: 
> https://github.com/0day-ci/linux/commits/Tobin-C-Harding/printk-hash-addresses-printed-with-p/20171024-231922

It's not clear to me which of the various versions this test ran
against, but it seems like the printf self-tests got very confused by
the results:

> [   40.275423] test_printf: kvasprintf(..., "%p %p", ...) returned '3cf9adbe 
> eff717bf', expected '01234567 fedcba98'
> [   40.296739] test_printf: vsnprintf(buf, 256, "|%-*p|%*p|", ...) returned 
> 19, expected 39
> [   40.322776] test_printf: vsnprintf(buf, 16, "|%-*p|%*p|", ...) returned 
> 19, expected 39
> [   40.334834] test_printf: vsnprintf(buf, 0, "|%-*p|%*p|", ...) returned 19, 
> expected 39

I assume v10 will fix the width issues, but probably not the value tests...

And it claims a use-after-free, too:

> [   39.757461] The buggy address belongs to the object at 22cb34bb
> [   39.757461]  which belongs to the cache kmalloc-32 of size 32
> [   39.757461] The buggy address is located 0 bytes inside of
> [   39.757461]  32-byte region [22cb34bb, 24ac3a60)

Which becomes rather unreadable, since the address got hashed. :P

-Kees

-- 
Kees Cook
Pixel Security

Re: [lkp-robot] [printk] 7f7c60e066: BUG:KASAN:slab-out-of-bounds

[Kees Cook]

On Wed, Oct 25, 2017 at 9:22 AM, kernel test robot
 wrote:
>
> FYI, we noticed the following commit (built with gcc-4.9):
>
> commit: 7f7c60e0663645e757e520245606fde9c6e326bb ("printk: hash addresses 
> printed with %p")
> url: 
> https://github.com/0day-ci/linux/commits/Tobin-C-Harding/printk-hash-addresses-printed-with-p/20171024-231922

It's not clear to me which of the various versions this test ran
against, but it seems like the printf self-tests got very confused by
the results:

> [   40.275423] test_printf: kvasprintf(..., "%p %p", ...) returned '3cf9adbe 
> eff717bf', expected '01234567 fedcba98'
> [   40.296739] test_printf: vsnprintf(buf, 256, "|%-*p|%*p|", ...) returned 
> 19, expected 39
> [   40.322776] test_printf: vsnprintf(buf, 16, "|%-*p|%*p|", ...) returned 
> 19, expected 39
> [   40.334834] test_printf: vsnprintf(buf, 0, "|%-*p|%*p|", ...) returned 19, 
> expected 39

I assume v10 will fix the width issues, but probably not the value tests...

And it claims a use-after-free, too:

> [   39.757461] The buggy address belongs to the object at 22cb34bb
> [   39.757461]  which belongs to the cache kmalloc-32 of size 32
> [   39.757461] The buggy address is located 0 bytes inside of
> [   39.757461]  32-byte region [22cb34bb, 24ac3a60)

Which becomes rather unreadable, since the address got hashed. :P

-Kees

-- 
Kees Cook
Pixel Security

[lkp-robot] [printk] 7f7c60e066: BUG:KASAN:slab-out-of-bounds

[kernel test robot]

FYI, we noticed the following commit (built with gcc-4.9):

commit: 7f7c60e0663645e757e520245606fde9c6e326bb ("printk: hash addresses 
printed with %p")
url: 
https://github.com/0day-ci/linux/commits/Tobin-C-Harding/printk-hash-addresses-printed-with-p/20171024-231922


in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


++++
|| 6cff0a118f | 7f7c60e066 |
++++
| boot_successes | 26 | 0  |
| boot_failures  | 16 | 49 |
| BUG:soft_lockup-CPU##stuck_for#s   | 16 ||
| Kernel_panic-not_syncing:softlockup:hung_tasks | 16 ||
| BUG:KASAN:slab-out-of-bounds   | 0  | 49 |
++++



[   39.757461] BUG: KASAN: slab-out-of-bounds in __test+0xee/0x13f
[   39.757461] Read of size 34 at addr 22cb34bb by task swapper/0/1
[   39.757461] 
[   39.757461] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.14.0-rc6-00013-g7f7c60e #1
[   39.757461] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   39.757461] Call Trace:
[   39.757461]  dump_stack+0xb0/0xf2
[   39.757461]  print_address_description+0x63/0x2b0
[   39.757461]  kasan_report+0x1fb/0x320
[   39.757461]  ? __test+0xee/0x13f
[   39.757461]  check_memory_region+0x142/0x1a0
[   39.757461]  __asan_loadN+0xf/0x20
[   39.757461]  __test+0xee/0x13f
[   39.757461]  test_printf_init+0x657/0x1378
[   39.757461]  ? test_sort_init+0xff/0x10d
[   39.757461]  ? kfree+0x8b/0x200
[   39.757461]  ? test_sort_init+0xff/0x10d
[   39.757461]  ? __test+0x13f/0x13f
[   39.757461]  do_one_initcall+0x9d/0x19a
[   39.757461]  kernel_init_freeable+0x1be/0x24b
[   39.757461]  ? rest_init+0xe0/0xe0
[   39.757461]  kernel_init+0x13/0x120
[   39.757461]  ? rest_init+0xe0/0xe0
[   39.757461]  ret_from_fork+0x25/0x30
[   39.757461] 
[   39.757461] Allocated by task 1:
[   39.757461]  save_stack_trace+0x1b/0x20
[   39.757461]  kasan_kmalloc+0xd7/0x180
[   39.757461]  kasan_slab_alloc+0x12/0x20
[   39.757461]  __kmalloc_track_caller+0x107/0x260
[   39.757461]  kvasprintf+0x55/0xb0
[   39.757461]  __test+0xd2/0x13f
[   39.757461]  test_printf_init+0x657/0x1378
[   39.757461]  do_one_initcall+0x9d/0x19a
[   39.757461]  kernel_init_freeable+0x1be/0x24b
[   39.757461]  kernel_init+0x13/0x120
[   39.757461]  ret_from_fork+0x25/0x30
[   39.757461] 
[   39.757461] Freed by task 1:
[   39.757461]  save_stack_trace+0x1b/0x20
[   39.757461]  kasan_slab_free+0xb9/0x190
[   39.757461]  kfree+0x8b/0x200
[   39.757461]  do_copy+0x6e/0xe0
[   39.757461]  write_buffer+0x37/0x4a
[   39.757461]  flush_buffer+0x38/0xa2
[   39.757461]  __gunzip+0x3b7/0x49e
[   39.757461]  gunzip+0x11/0x13
[   39.757461]  unpack_to_rootfs+0x19a/0x313
[   39.757461]  populate_rootfs+0xa6/0x131
[   39.757461]  do_one_initcall+0x9d/0x19a
[   39.757461]  kernel_init_freeable+0x1be/0x24b
[   39.757461]  kernel_init+0x13/0x120
[   39.757461]  ret_from_fork+0x25/0x30
[   39.757461] 
[   39.757461] The buggy address belongs to the object at 22cb34bb
[   39.757461]  which belongs to the cache kmalloc-32 of size 32
[   39.757461] The buggy address is located 0 bytes inside of
[   39.757461]  32-byte region [22cb34bb, 24ac3a60)
[   39.757461] The buggy address belongs to the page:
[   39.757461] page:a7cc2f90 count:1 mapcount:0 mapping:  (null) 
index:0x0
[   39.757461] flags: 0x4100(slab)
[   39.757461] raw: 4100   
000180550055
[   39.757461] raw: ea5db400 00060006 88001a001a00 

[   39.757461] page dumped because: kasan: bad access detected
[   39.757461] 
[   39.757461] Memory state around the buggy address:
[   39.757461]  1c0e72a5: fb fb fc fc fb fb fb fb fc fc fb fb fb fb fc fc
[   39.757461]5e1f6c: fb fb fb fb fc fc fb fb fb fb fc fc 00 00 00 00
[   39.757461] >24ac3a60: fc fc fb fb fb fb fc fc fb fb fb fb fc fc fb fb
[   39.757461]^
[   39.757461]  c354f823: fb fb fc fc fb fb fb fb fc fc fb fb fb fb fc fc
[   39.757461]  149d6220: fb fb fb fb fc fc fb fb fb fb fc fc fb fb fb fb
[   39.757461] 
==
[   39.757461] Disabling lock debugging due to kernel taint
[   40.275423] test_printf: kvasprintf(..., "%p %p", ...) returned '3cf9adbe 
eff717bf', expected '01234567 fedcba98'
[   40.296739] 

[lkp-robot] [printk] 7f7c60e066: BUG:KASAN:slab-out-of-bounds

[kernel test robot]

FYI, we noticed the following commit (built with gcc-4.9):

commit: 7f7c60e0663645e757e520245606fde9c6e326bb ("printk: hash addresses 
printed with %p")
url: 
https://github.com/0day-ci/linux/commits/Tobin-C-Harding/printk-hash-addresses-printed-with-p/20171024-231922


in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


++++
|| 6cff0a118f | 7f7c60e066 |
++++
| boot_successes | 26 | 0  |
| boot_failures  | 16 | 49 |
| BUG:soft_lockup-CPU##stuck_for#s   | 16 ||
| Kernel_panic-not_syncing:softlockup:hung_tasks | 16 ||
| BUG:KASAN:slab-out-of-bounds   | 0  | 49 |
++++



[   39.757461] BUG: KASAN: slab-out-of-bounds in __test+0xee/0x13f
[   39.757461] Read of size 34 at addr 22cb34bb by task swapper/0/1
[   39.757461] 
[   39.757461] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.14.0-rc6-00013-g7f7c60e #1
[   39.757461] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   39.757461] Call Trace:
[   39.757461]  dump_stack+0xb0/0xf2
[   39.757461]  print_address_description+0x63/0x2b0
[   39.757461]  kasan_report+0x1fb/0x320
[   39.757461]  ? __test+0xee/0x13f
[   39.757461]  check_memory_region+0x142/0x1a0
[   39.757461]  __asan_loadN+0xf/0x20
[   39.757461]  __test+0xee/0x13f
[   39.757461]  test_printf_init+0x657/0x1378
[   39.757461]  ? test_sort_init+0xff/0x10d
[   39.757461]  ? kfree+0x8b/0x200
[   39.757461]  ? test_sort_init+0xff/0x10d
[   39.757461]  ? __test+0x13f/0x13f
[   39.757461]  do_one_initcall+0x9d/0x19a
[   39.757461]  kernel_init_freeable+0x1be/0x24b
[   39.757461]  ? rest_init+0xe0/0xe0
[   39.757461]  kernel_init+0x13/0x120
[   39.757461]  ? rest_init+0xe0/0xe0
[   39.757461]  ret_from_fork+0x25/0x30
[   39.757461] 
[   39.757461] Allocated by task 1:
[   39.757461]  save_stack_trace+0x1b/0x20
[   39.757461]  kasan_kmalloc+0xd7/0x180
[   39.757461]  kasan_slab_alloc+0x12/0x20
[   39.757461]  __kmalloc_track_caller+0x107/0x260
[   39.757461]  kvasprintf+0x55/0xb0
[   39.757461]  __test+0xd2/0x13f
[   39.757461]  test_printf_init+0x657/0x1378
[   39.757461]  do_one_initcall+0x9d/0x19a
[   39.757461]  kernel_init_freeable+0x1be/0x24b
[   39.757461]  kernel_init+0x13/0x120
[   39.757461]  ret_from_fork+0x25/0x30
[   39.757461] 
[   39.757461] Freed by task 1:
[   39.757461]  save_stack_trace+0x1b/0x20
[   39.757461]  kasan_slab_free+0xb9/0x190
[   39.757461]  kfree+0x8b/0x200
[   39.757461]  do_copy+0x6e/0xe0
[   39.757461]  write_buffer+0x37/0x4a
[   39.757461]  flush_buffer+0x38/0xa2
[   39.757461]  __gunzip+0x3b7/0x49e
[   39.757461]  gunzip+0x11/0x13
[   39.757461]  unpack_to_rootfs+0x19a/0x313
[   39.757461]  populate_rootfs+0xa6/0x131
[   39.757461]  do_one_initcall+0x9d/0x19a
[   39.757461]  kernel_init_freeable+0x1be/0x24b
[   39.757461]  kernel_init+0x13/0x120
[   39.757461]  ret_from_fork+0x25/0x30
[   39.757461] 
[   39.757461] The buggy address belongs to the object at 22cb34bb
[   39.757461]  which belongs to the cache kmalloc-32 of size 32
[   39.757461] The buggy address is located 0 bytes inside of
[   39.757461]  32-byte region [22cb34bb, 24ac3a60)
[   39.757461] The buggy address belongs to the page:
[   39.757461] page:a7cc2f90 count:1 mapcount:0 mapping:  (null) 
index:0x0
[   39.757461] flags: 0x4100(slab)
[   39.757461] raw: 4100   
000180550055
[   39.757461] raw: ea5db400 00060006 88001a001a00 

[   39.757461] page dumped because: kasan: bad access detected
[   39.757461] 
[   39.757461] Memory state around the buggy address:
[   39.757461]  1c0e72a5: fb fb fc fc fb fb fb fb fc fc fb fb fb fb fc fc
[   39.757461]5e1f6c: fb fb fb fb fc fc fb fb fb fb fc fc 00 00 00 00
[   39.757461] >24ac3a60: fc fc fb fb fb fb fc fc fb fb fb fb fc fc fb fb
[   39.757461]^
[   39.757461]  c354f823: fb fb fc fc fb fb fb fb fc fc fb fb fb fb fc fc
[   39.757461]  149d6220: fb fb fb fb fc fc fb fb fb fb fc fc fb fb fb fb
[   39.757461] 
==
[   39.757461] Disabling lock debugging due to kernel taint
[   40.275423] test_printf: kvasprintf(..., "%p %p", ...) returned '3cf9adbe 
eff717bf', expected '01234567 fedcba98'
[   40.296739]