linux-kernel - Re: [next-20260120] KASAN: maybe wild-memory-access in select_task_rq

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <5vif6anhufcalcsrsmlmhssxzajd5jo4ztnnnuoqvdfwjta6vq@6yvfxq6fci22>
Date: Wed, 21 Jan 2026 18:07:22 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>, 
	Peter Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...nel.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, Steven Rostedt <rostedt@...dmis.org>, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [next-20260120] KASAN: maybe wild-memory-access in
 select_task_rq_fair

On (26/01/20 21:11), Paul E. McKenney wrote:
> On Wed, Jan 21, 2026 at 01:03:02PM +0900, Sergey Senozhatsky wrote:
> > Hello,
> > 
> > I'm seeing the following KASAN report on next-20260120 (qemu x86_64).
> > There seems to be a lot of stuff going on in the call trace:
> 
> I'll say!
> 
> > [    1.714941][  T136] ==================================================================
> > [    1.715713][    C0] Oops: general protection fault, probably for non-canonical address 0xeb1125008e9810b0: 0000 [#1] SMP KASAN
> > [    1.715702][  T136] ------------[ cut here ]------------
> > [    1.716702][    C0] KASAN: maybe wild-memory-access in range [0x5889480474c08580-0x5889480474c08587]
> > [    1.716702][    C0] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-rc6-next-20260120-00004-g7dff00c348a6 #645 PREEMPT 
> > [    1.715702][  T136] WARNING: kernel/rcu/tree_plugin.h:443 at __rcu_read_unlock+0xb6/0xe0, CPU#2: devtmpf.X/136
> 
> This is most likely to happen when you do an rcu_read_unlock()
> without a matchine rcu_read_lock().  It could also happen if you
> nested rcu_read_lock() a billion deep.  Or if RCU had a strange
> bug.  Or if someone corrupted the current task_struct structure's
> =>rcu_read_lock_nesting field.

RCU warn is not always trigger-able, sometimes it's might_sleep
assertion:

[    1.593114][  T136] BUG: sleeping function called from invalid context at ./include/linux/sched/mm.h:323
[    1.595588][    C0] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000087: 0000 [#1] SMP KASAN
[    1.596578][    C0] KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f]
[    1.596578][    C0] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-rc6-next-20260120-00004-g7dff00c348a6 #676 PREEMPT 
[    1.596578][    C0] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.1 11/11/2019
[    1.596578][    C0] RIP: 0010:select_task_rq_fair+0x520/0x810
[..]