linux-kernel - Re: [PATCH] kasan: don't call find_vm_area() in in

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: <aGTRhaHrkjCNb2S4@e129823.arm.com>
Date: Wed, 2 Jul 2025 07:28:21 +0100
From: Yeoreum Yun <yeoreum.yun@....com>
To: Byungchul Park <byungchul@...com>
Cc: ryabinin.a.a@...il.com, glider@...gle.com, andreyknvl@...il.com,
	dvyukov@...gle.com, vincenzo.frascino@....com,
	kpm@...ux-foundation.org, bigeasy@...utronix.de,
	clrkwllms@...nel.org, rostedt@...dmis.org,
	max.byungchul.park@...il.com, kasan-dev@...glegroups.com,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	linux-rt-devel@...ts.linux.dev, nd@....com,
	Yunseong Kim <ysk@...lloc.com>, kernel_team@...ynix.com
Subject: Re: [PATCH] kasan: don't call find_vm_area() in in_interrupt() for
 possible deadlock

Hi Byungchul,

> > >
> > > CPU0                                CPU1
> > > vmalloc();
> > >  alloc_vmap_area();
> > >   spin_lock(&vn->busy.lock)
> > 			^
> > 	Here, it should be spin_lock_bh(&vn->busy.lock).
>
> spin_lock_irqsave(&vn->busy.lock) might be even better, assuming
> find_vm_area() could be called with a critcal section of *_irq() or
> something.

Agree for this change and I also thought about it.
But, I'm not sure changing to spin_lock_irqsave() is *better*
since it makes a unexpected schedule delay whenever
vmalloc_info_show() is called via proc.

Also, I think the find_vm_area() is designed for task context not
for atomic context. so it seems the misusage in the kasan.

Am I missing something?

Thanks.

--
Sincerely,
Yeoreum Yun