linux-kernel - Re: [syzbot] [fs?] BUG: sleeping function called from invalid context in vfree (2)

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

Message-ID: <4tu4bjs72dqx2pbamu7mc72dg5fxmrbaklbljyppxllr2hccmf@ig75eaoswryd>
Date: Mon, 18 Aug 2025 05:40:58 -0700
From: Breno Leitao <leitao@...ian.org>
To: Hillf Danton <hdanton@...a.com>
Cc: syzbot <syzbot+f65a2014305525a9f816@...kaller.appspotmail.com>, 
	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, 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" ?

> --- 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?