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: <20250818131902.5039-1-hdanton@sina.com>
Date: Mon, 18 Aug 2025 21:19:01 +0800
From: Hillf Danton <hdanton@...a.com>
To: Breno Leitao <leitao@...ian.org>
Cc: syzbot <syzbot+f65a2014305525a9f816@...kaller.appspotmail.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org,
	syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [fs?] BUG: sleeping function called from invalid context in vfree (2)

On Mon, 18 Aug 2025 05:40:58 -0700 Breno Leitao wrote:
> On Mon, Aug 18, 2025 at 06:07:57PM +0800, Hillf Danton wrote:
> > > Date: Mon, 18 Aug 2025 01:05:33 -0700	[thread overview]
> > > Hello,
> > > 
> > > syzbot found the following issue on:
> > > 
> > > HEAD commit:    8f5ae30d69d7 Linux 6.17-rc1
> > > git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=15232442580000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=8c5ac3d8b8abfcb
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=f65a2014305525a9f816
> > > userspace arch: arm64
> > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=14cbaba2580000
> > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1157faf0580000
> > 
> > #syz test upstream master
> 
> I was hitting this issue and I've tested it and the BUG is not there any
> more.
> 
> Do you know which commit caused this "regression" ?
> 
Looks like the tglx dude's work [1]

[1] Subject: [tip: locking/urgent] futex: Move futex cleanup to __mmdrop()
https://lore.kernel.org/lkml/175414093081.1420.8088049602488588887.tip-bot2@tip-bot2/

> > --- x/include/linux/mm_types.h
> > +++ y/include/linux/mm_types.h
> >
> > @@ -689,9 +697,8 @@ void __mmdrop(struct mm_struct *mm)
> >  	mm_pasid_drop(mm);
> >  	mm_destroy_cid(mm);
> >  	percpu_counter_destroy_many(mm->rss_stat, NR_MM_COUNTERS);
> > -	futex_hash_free(mm);
> > -
> > -	free_mm(mm);
> > +	INIT_WORK(&mm->drop_work, mmdrop_workfn);
> 
> should INIT_WORK() be called at setup phase other than at any 
> __mmdrop()?
> 
> Also, is the scheduling overhead a concern here?
> 
Feel free to forget/ignore the tecknique details like your concerns
here because the diff is only to cut the added vfree in atomic context
from a square skull.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ