linux-kernel - Re: [PATCH] mm/percpu: prevent concurrency problem for pcpu_nr

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: <CAO9qdTEidRnO4O_D7Z1jKZTyJadFyEyWBnfitTz8t1CdBaM1nw@mail.gmail.com>
Date: Thu, 3 Jul 2025 13:45:36 +0900
From: Jeongjun Park <aha310510@...il.com>
To: "Christoph Lameter (Ampere)" <cl@...two.org>
Cc: dennis@...nel.org, tj@...nel.org, akpm@...ux-foundation.org, 
	vbabka@...e.cz, rientjes@...gle.com, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, 
	syzbot+e5bd32b79413e86f389e@...kaller.appspotmail.com
Subject: Re: [PATCH] mm/percpu: prevent concurrency problem for
 pcpu_nr_populated read with spin lock

Christoph Lameter (Ampere) <cl@...two.org> wrote:
>
> On Wed, 2 Jul 2025, Jeongjun Park wrote:
>
> > diff --git a/mm/percpu.c b/mm/percpu.c
> > index b35494c8ede2..0f98b857fb36 100644
> > --- a/mm/percpu.c
> > +++ b/mm/percpu.c
> > @@ -3355,7 +3355,13 @@ void __init setup_per_cpu_areas(void)
> >   */
> >  unsigned long pcpu_nr_pages(void)
> >  {
> > -     return pcpu_nr_populated * pcpu_nr_units;
> > +     unsigned long flags, ret;
> > +
> > +     spin_lock_irqsave(&pcpu_lock, flags);
> > +     ret = pcpu_nr_populated * pcpu_nr_units;
> > +     spin_unlock_irqrestore(&pcpu_lock, flags);
>
>
> Ummm.. What? You are protecting a single read with a spinlock? There needs
> to be some updating of data somewhere for this to make sense.
>
>
> Unless a different critical section protected by the lock sets the value
> intermittendly to something you are not allowed to see before a final
> store of a valid value. But that would be unusual.
>
> This is an academic exercise or did you really see a problem?
>
> What is racing?
>
>

This patch is by no means an academic exercise.

As written in the reported tag, This race has actually been reported
in syzbot [1].

[1]: https://syzkaller.appspot.com/bug?extid=e5bd32b79413e86f389e

pcpu_nr_populated is currently being write in pcpu_chunk_populated()
and pcpu_chunk_depopulated(), and since this two functions perform
pcpu_nr_populated write under the protection of pcpu_lock, there is no
race for write/write.

However, since pcpu_nr_pages(), which performs a read operation on
pcpu_nr_populated, is not protected by pcpu_lock, races between read/write
can easily occur.

Therefore, I think it is appropriate to protect it through pcpu_lock
according to the comment written in the definition of pcpu_nr_populated.

--
Regards,

Jeongjun Park