linux-kernel - Re: [PATCH RESEND v2 1/2] ucount: Fix atomic_long_inc

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aH9eXGb7QJ7fZl1t@J2N7QTR9R3>
Date: Tue, 22 Jul 2025 10:48:12 +0100
From: Mark Rutland <mark.rutland@....com>
To: Uros Bizjak <ubizjak@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Alexey Gladkov <legion@...nel.org>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	MengEn Sun <mengensun@...cent.com>,
	Thomas Weißschuh <linux@...ssschuh.net>
Subject: Re: [PATCH RESEND v2 1/2] ucount: Fix atomic_long_inc_below()
 argument type

On Tue, Jul 22, 2025 at 08:44:29AM +0200, Uros Bizjak wrote:
> On Tue, Jul 22, 2025 at 12:43 AM Andrew Morton
> <akpm@...ux-foundation.org> wrote:
> >
> > On Mon, 21 Jul 2025 19:45:57 +0200 Uros Bizjak <ubizjak@...il.com> wrote:
> >
> > > The type of u argument of atomic_long_inc_below() should be long
> > > to avoid unwanted truncation to int.
> > >
> > > Fixes: f9c82a4ea89c ("Increase size of ucounts to atomic_long_t")
> >
> > Please (always!) provide a description of the userspace-visible effects
> > of the bug.  That way I (and others) can decide whether the fix should
> > be backported.  And people will be able to determine whether this patch
> > may fix problems which they are observing.  Thanks.
> 
> The patch fixes the wrong argument type of an internal function to
> prevent unwanted argument truncation. It fixes an internal locking
> primitive; it should not have any direct effect on userspace.

AFAICT there's no problem in practice because atomic_long_inc_below() is
only used by inc_ucount(), and it looks like the value is constrained
between 0 and INT_MAX.

In inc_ucount() the limit value is taken from
user_namespace::ucount_max[], and AFAICT that's only written by sysctls,
to the table setup by setup_userns_sysctls(), where UCOUNT_ENTRY()
limits the value between 0 and INT_MAX.

This is certainly a cleanup, but there might be no functional issue in
practice as above.

Mark.