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: <CAO9qdTG0uDcG5ydXbj5XZdsdH=pD2yHaq9dR=N=Nq5QvUMvuBA@mail.gmail.com>
Date: Thu, 3 Jul 2025 14:19:34 +0900
From: Jeongjun Park <aha310510@...il.com>
To: Shakeel Butt <shakeel.butt@...ux.dev>
Cc: dennis@...nel.org, tj@...nel.org, cl@...two.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

Shakeel Butt <shakeel.butt@...ux.dev> wrote:
>
> On Wed, Jul 02, 2025 at 05:27:49PM +0900, Jeongjun Park wrote:
> > Read/Write to pcpu_nr_populated should be performed while protected
> > by pcpu_lock. However, pcpu_nr_pages() reads pcpu_nr_populated without any
> > protection, which causes a data race between read/write.
> >
> > Therefore, when reading pcpu_nr_populated in pcpu_nr_pages(), it should be
> > modified to be protected by pcpu_lock.
> >
> > Reported-by: syzbot+e5bd32b79413e86f389e@...kaller.appspotmail.com
> > Fixes: 7e8a6304d541 ("/proc/meminfo: add percpu populated pages count")
> > Signed-off-by: Jeongjun Park <aha310510@...il.com>
> > ---
> >  mm/percpu.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > 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;
>
> No need for the lock as I think race is fine here. Use something like
> the following and add a comment.
>
>         data_race(READ_ONCE(pcpu_nr_populated)) * pcpu_nr_units;
>

This race itself is not a critical security vuln, but it is a read/write
race that actually occurs. Writing to pcpu_nr_populated is already
systematically protected through pcpu_lock, so why do you think you can
ignore the data race only when reading?

--
Regards,

Jeongjun Park