linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Erhard Furtner <erhard_f@mailbox.org>
To: linux-mm@kvack.org
Cc: kasan-dev@googlegroups.com, kees@kernel.org
Subject: Re: BUG: KASAN: vmalloc-out-of-bounds in vrealloc_noprof+0x195/0x220 at running fortify_kunit (v6.15-rc1, x86_64)
Date: Mon, 21 Apr 2025 12:04:08 +0200	[thread overview]
Message-ID: <20250421120408.04d7abdf@outsider.home> (raw)
In-Reply-To: <20250408192503.6149a816@outsider.home>

Greetings!

fortify_test_alloc_size_kvmalloc_const test failure still in v6.15-rc3, also with a 'GCC14 -O2'-built kernel:

==================================================================
BUG: KASAN: vmalloc-out-of-bounds in vrealloc_noprof+0x2a2/0x370
Read of size 6291456 at addr ffffc9000e200000 by task kunit_try_catch/4317

CPU: 21 UID: 0 PID: 4317 Comm: kunit_try_catch Tainted: G                 N  6.15.0-rc3-Zen3 #11 PREEMPT 
Tainted: [N]=TEST
Hardware name: To Be Filled By O.E.M. B550M Pro4/B550M Pro4, BIOS L3.46 08/20/2024
Call Trace:
 <TASK>
 dump_stack_lvl+0x4a/0x70
 print_report+0x132/0x4e0
 ? __rwlock_init+0x120/0x120
 ? vrealloc_noprof+0x2a2/0x370
 kasan_report+0xd9/0x110
 ? vrealloc_noprof+0x2a2/0x370
 ? fortify_test_alloc_size_kvmalloc_const+0x4892/0xa3d0 [fortify_kunit]
 kasan_check_range+0x113/0x210
 __asan_memcpy+0x1f/0x70
 vrealloc_noprof+0x2a2/0x370
 ? srso_alias_return_thunk+0x5/0xfbef5
 fortify_test_alloc_size_kvmalloc_const+0x4892/0xa3d0 [fortify_kunit]
 ? fortify_test_alloc_size_vmalloc_const+0x2a30/0x2a30 [fortify_kunit]
 ? srso_alias_return_thunk+0x5/0xfbef5
 ? srso_alias_return_thunk+0x5/0xfbef5
 ? ktime_get_ts64+0x7a/0x220
 ? fortify_test_init+0x2be/0x460 [fortify_kunit]
 kunit_try_run_case+0x199/0x2b0 [kunit]
 ? kunit_try_run_case_cleanup+0xe0/0xe0 [kunit]
 ? srso_alias_return_thunk+0x5/0xfbef5
 ? do_raw_spin_unlock+0x4f/0x220
 ? kunit_try_run_case_cleanup+0xe0/0xe0 [kunit]
 ? kunit_mem_assert_format+0x460/0x460 [kunit]
 kunit_generic_run_threadfn_adapter+0x7b/0xe0 [kunit]
 kthread+0x349/0x6c0
 ? kthread_is_per_cpu+0xd0/0xd0
 ? kthread_is_per_cpu+0xd0/0xd0
 ? kthread_is_per_cpu+0xd0/0xd0
 ret_from_fork+0x2b/0x70
 ? kthread_is_per_cpu+0xd0/0xd0
 ret_from_fork_asm+0x11/0x20
 </TASK>

The buggy address belongs to the virtual mapping at
 [ffffc9000e200000, ffffc9000e801000) created by:
 fortify_test_alloc_size_kvmalloc_const+0x4788/0xa3d0 [fortify_kunit]

The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fab41f0a pfn:0x128000
flags: 0x4000000000000000(zone=1)
raw: 4000000000000000 0000000000000000 dead000000000122 0000000000000000
raw: 00000007fab41f0a 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffffc9000e600f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffc9000e600f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffc9000e601000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
                   ^
 ffffc9000e601080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
 ffffc9000e601100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
==================================================================
Disabling lock debugging due to kernel taint
    not ok 7 fortify_test_alloc_size_kvmalloc_const
[...]

Regards,
Erhard


On Tue, 8 Apr 2025 19:25:03 +0200
Erhard Furtner <erhard_f@mailbox.org> wrote:

> Greetings!
> 
> I gave v6.15-rc1 a test ride on my Ryzen 5950 system with some debugging options turned on, getting a KASAN vmalloc-out-of-bounds hit at running fortify_kunit test:
> 
> [...]
> TAP version 1
> 1..1
>     KTAP version 1
>     # Subtest: fortify
>     # module: fortify_kunit
>     1..26
>     ok 1 fortify_test_known_sizes
>     ok 2 fortify_test_control_flow_split
>     ok 3 fortify_test_alloc_size_kmalloc_const
>     ok 4 fortify_test_alloc_size_kmalloc_dynamic
>     ok 5 fortify_test_alloc_size_vmalloc_const
>     ok 6 fortify_test_alloc_size_vmalloc_dynamic
> ==================================================================
> BUG: KASAN: vmalloc-out-of-bounds in vrealloc_noprof+0x195/0x220
> Read of size 6291456 at addr ffffc90015c00000 by task kunit_try_catch/4334
> 
> CPU: 15 UID: 0 PID: 4334 Comm: kunit_try_catch Tainted: G                 N  6.15.0-rc1-Zen3 #6 PREEMPT 
> Tainted: [N]=TEST
> Hardware name: To Be Filled By O.E.M. B550M Pro4/B550M Pro4, BIOS L3.46 08/20/2024
> Call Trace:
>  <TASK>
>  dump_stack_lvl+0x2a/0x90
>  print_report+0x17a/0x520
>  ? srso_alias_return_thunk+0x5/0xfbef5
>  ? vrealloc_noprof+0x195/0x220
>  kasan_report+0xb9/0x100
>  ? vrealloc_noprof+0x195/0x220
>  kasan_check_range+0x184/0x190
>  ? vrealloc_noprof+0x195/0x220
>  __asan_memcpy+0x25/0x70
>  vrealloc_noprof+0x195/0x220
>  ? fortify_test_alloc_size_kvmalloc_const+0x2eae/0x7170 [fortify_kunit]
>  fortify_test_alloc_size_kvmalloc_const+0x2eae/0x7170 [fortify_kunit]
>  kunit_try_run_case+0x119/0x340 [kunit]
>  ? kunit_cleanup+0x120/0x120 [kunit]
>  kunit_generic_run_threadfn_adapter+0x73/0x100 [kunit]
>  kthread+0x46a/0x570
>  ? kunit_try_catch_run+0x620/0x620 [kunit]
>  ? kthread_blkcg+0xb0/0xb0
>  ret_from_fork+0x3c/0x70
>  ? kthread_blkcg+0xb0/0xb0
>  ret_from_fork_asm+0x11/0x20
>  </TASK>
> 
> The buggy address belongs to the virtual mapping at
>  [ffffc90015c00000, ffffc90016201000) created by:
>  fortify_test_alloc_size_kvmalloc_const+0x2dfb/0x7170 [fortify_kunit]
> 
> The buggy address belongs to the physical page:
> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7f281927d pfn:0x128600
> flags: 0x4000000000000000(zone=1)
> raw: 4000000000000000 0000000000000000 dead000000000122 0000000000000000
> raw: 00000007f281927d 0000000000000000 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
> 
> Memory state around the buggy address:
>  ffffc90016000f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  ffffc90016000f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >ffffc90016001000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8  
>                    ^
>  ffffc90016001080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>  ffffc90016001100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> ==================================================================
> Disabling lock debugging due to kernel taint
>     not ok 7 fortify_test_alloc_size_kvmalloc_const
>     ok 8 fortify_test_alloc_size_kvmalloc_dynamic
>     ok 9 fortify_test_alloc_size_devm_kmalloc_const
>     ok 10 fortify_test_alloc_size_devm_kmalloc_dynamic
>     ok 11 fortify_test_realloc_size
>     ok 12 fortify_test_strlen
>     ok 13 fortify_test_strnlen
>     ok 14 fortify_test_strcpy
>     ok 15 fortify_test_strncpy
>     ok 16 fortify_test_strscpy
>     ok 17 fortify_test_strcat
>     ok 18 fortify_test_strncat
>     ok 19 fortify_test_strlcat
>     ok 20 fortify_test_memcpy
>     ok 21 fortify_test_memmove
>     ok 22 fortify_test_memscan
>     ok 23 fortify_test_memchr
>     ok 24 fortify_test_memchr_inv
>     ok 25 fortify_test_memcmp
>     ok 26 fortify_test_kmemdup
> # fortify: pass:25 fail:1 skip:0 total:26
> # Totals: pass:25 fail:1 skip:0 total:26
> not ok 1 fortify
> 
> 
> Kernel .config attached.


  reply	other threads:[~2025-04-21 10:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-08 17:25 Erhard Furtner
2025-04-21 10:04 ` Erhard Furtner [this message]
2025-04-22 16:50   ` Kees Cook
2025-04-22 22:44     ` Erhard Furtner
2025-04-23  6:49       ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250421120408.04d7abdf@outsider.home \
    --to=erhard_f@mailbox.org \
    --cc=kasan-dev@googlegroups.com \
    --cc=kees@kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox