linux-kernel - Re: [syzbot] [mm?] WARNING: bad unlock balance in copy

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250918084827.TWzT-hc4@linutronix.de>
Date: Thu, 18 Sep 2025 10:48:27 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: syzbot <syzbot+80cb3cc5c14fad191a10@...kaller.appspotmail.com>,
	Liam.Howlett@...cle.com, akpm@...ux-foundation.org,
	bsegall@...gle.com, david@...hat.com, dietmar.eggemann@....com,
	juri.lelli@...hat.com, kees@...nel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	lorenzo.stoakes@...cle.com, mgorman@...e.de, mhocko@...e.com,
	mingo@...hat.com, peterz@...radead.org, rostedt@...dmis.org,
	rppt@...nel.org, surenb@...gle.com, syzkaller-bugs@...glegroups.com,
	vincent.guittot@...aro.org, vschneid@...hat.com
Subject: Re: [syzbot] [mm?] WARNING: bad unlock balance in copy_process

On 2025-09-18 10:35:24 [+0200], Vlastimil Babka wrote:
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+80cb3cc5c14fad191a10@...kaller.appspotmail.com
> > 
> > =====================================
> > WARNING: bad unlock balance detected!
> > syzkaller #0 Not tainted
> > -------------------------------------
> > syz.1.48/6865 is trying to release lock (&sighand->siglock) at:
> > [<ffff8000803b8634>] spin_unlock include/linux/spinlock.h:391 [inline]
> > [<ffff8000803b8634>] copy_process+0x22d4/0x31ec kernel/fork.c:2432
> 
> bad_fork_core_free:
>         sched_core_free(p);
>         spin_unlock(&current->sighand->siglock); <- here
> 
> Sebastian, I think it's your 7c4f75a21f63 ("futex: Allow automatic
> allocation of process wide futex hash") adding a "goto bad_fork_core_free;"
> from a place that doesn't yet have current->sighand->siglock locked?

Yes. Judging from -rc6, if futex_hash_allocate_default() fails we hold
neither siglock nor tasklist_lock. sched_core_free() looks also bad as
the cookie was allocated later in sched_core_fork(). sched_cgroup_fork()
does nothing special. So it should be

diff --git a/kernel/fork.c b/kernel/fork.c
index c4ada32598bd5..6ca8689a83b5b 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2295,7 +2295,7 @@ __latent_entropy struct task_struct *copy_process(
 	if (need_futex_hash_allocate_default(clone_flags)) {
 		retval = futex_hash_allocate_default();
 		if (retval)
-			goto bad_fork_core_free;
+			goto bad_fork_cancel_cgroup;
 		/*
 		 * If we fail beyond this point we don't free the allocated
 		 * futex hash map. We assume that another thread will be created

Sebastian