linux-kernel - Re: [PATCH -next] x86: Prevent KASAN false positive warnings in __show

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ebaaa130-0041-4871-8352-d33e285147ac@huaweicloud.com>
Date: Thu, 21 Aug 2025 11:13:21 +0800
From: Tengda Wu <wutengda@...weicloud.com>
To: Dave Hansen <dave.hansen@...el.com>, x86@...nel.org
Cc: Andrey Ryabinin <ryabinin.a.a@...il.com>,
 Thomas Gleixner <tglx@...utronix.de>, Alexander Potapenko
 <glider@...gle.com>, Andrey Konovalov <andreyknvl@...il.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 Dmitry Vyukov <dvyukov@...gle.com>, Ingo Molnar <mingo@...hat.com>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next] x86: Prevent KASAN false positive warnings in
 __show_regs()



On 2025/8/21 5:36, Dave Hansen wrote:
> On 8/18/25 06:07, Tengda Wu wrote:
>> When process A accesses process B's `regs` from stack memory through
>> __show_regs(), the stack of process B keeps changing during runtime.
>> This causes false positives like "stack out-of-bounds" [1] or
>> "out-of-bounds" [2] warnings when reading `regs` contents.
> 
> Could you explain a little bit more how you know that these are false
> positives?

Thanks for the question. We believe this is a false positive caused by a
race condition during asynchronous stack tracing of a running process:

Process A (stack trace all processes)         Process B (running)
1. echo t > /proc/sysrq-trigger

show_trace_log_lvl
  regs = unwind_get_entry_regs()
  show_regs_if_on_stack(regs)
                                              2. The stack data pointed by
                                                 `regs` keeps changing, and
                                                 so are the markings in its
                                                 KASAN shadow region.
    __show_regs(regs)
      regs->ax, regs->bx, ...
        3. hit KASAN redzones, OOB

When process A stacks process B without suspending it, the continuous
changes in process B's stack (and corresponding KASAN shadow markings)
may cause process A to hit KASAN redzones when accessing obsolete `regs`
addresses, resulting in false positive reports.

A sample error log for this scenario is shown below:

[332706.551830] task:cat             state:R  running task     stack:0     pid:3983623 ppid:3977902 flags:0x00004002
[332706.551847] Call Trace:
[332706.551853]  <TASK>
[332706.551860]  __schedule+0x809/0x1050
[332706.551873]  ? __pfx___schedule+0x10/0x10
[332706.551885]  ? __stack_depot_save+0x34/0x340
[332706.551899]  schedule+0x82/0x160
[332706.551911]  io_schedule+0x68/0xa0
[332706.551923]  __folio_lock_killable+0x1db/0x410
[332706.551940]  ? __pfx___folio_lock_killable+0x10/0x10
[332706.551955]  ? __pfx_wake_page_function+0x10/0x10
[332706.551969]  ? __filemap_get_folio+0x4b/0x3d0
[332706.551982]  filemap_fault+0x67a/0xbd0
[332706.551996]  ? __pfx_filemap_fault+0x10/0x10
[332706.552008]  ? policy_node+0x8a/0xa0
[332706.552021]  ? __mod_node_page_state+0x23/0xf0
[332706.552035]  __do_fault+0x6d/0x340
[332706.552048]  do_cow_fault+0xdd/0x300
[332706.552061]  do_fault+0x141/0x1e0
[332706.552074]  __handle_mm_fault+0x839/0xa70
[332706.552089]  ? __pfx___handle_mm_fault+0x10/0x10
[332706.552105]  ? find_vma+0x6a/0x90
[332706.552117]  handle_mm_fault+0x27d/0x470
[332706.552132]  exc_page_fault+0x336/0x6d0
[332706.552145]  asm_exc_page_fault+0x22/0x30
[332706.552157] RIP: 0010:rep_stos_alternative+0x40/0x80                                         --- (1)
[332706.552173] Code: Unable to access opcode bytes at 0x7ffe929c4fd6.                           --- (2)
[332706.552181] RSP: 3fa6:ffff88ba5e554200 EFLAGS: ffffffff9d50c0e0 ORIG_RAX: ffff88ba5e554200   --- (3)
[332706.552195] ==================================================================
[332706.552324] BUG: KASAN: out-of-bounds in __show_regs+0x4b/0x340                              --- (4)
[332706.552433] Read of size 8 at addr ffff88d24999fb20 by task sysrq_t_test.sh/3977032

We focus on logs (1) to (4):
 * Log (1) shows the current regs->ip (a kernel-mode address);
 * Log (2) displays regs->ip - PROLOGUE_SIZE, which deviates significantly
   from kernel-mode addresses, indicating regs->ip has changed.
 * Log (3) then reveals anomalous values in regs->{ss,sp,flags}.
 * Finally, Log (4) reports a KASAN OOB error when accessing regs->bx.

Stack tracing a running task cannot guarantee the accuracy of the printed
regs values, but accessing regs addresses does not cause kernel instability.
Similar cases have been consistently handled this way in the past. [1][2]
We therefore consider this a KASAN false positive.

[1] https://lore.kernel.org/all/20220915150417.722975-40-glider@google.com/T/#u
[2] https://lore.kernel.org/all/5f6e80c4b0c7f7f0b6211900847a247cdaad753c.1479398226.git.jpoimboe@redhat.com/T/#u