linux-kernel - Re: [PATCH v5 2/3] man/man2/prctl.2, PR_FUTEX_HASH_SET_SLOTS.2const: Document PR_FUTEX_HASH_SET

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

Message-ID: <wygherozbi27pom3xgfcev6pweliuap44cli2vuqhyaqth3dkf@vrkh2iu75tyn>
Date: Thu, 21 Aug 2025 21:14:11 +0200
From: Alejandro Colomar <alx@...nel.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org, linux-man@...r.kernel.org, 
	André Almeida <andrealmeid@...lia.com>, Darren Hart <dvhart@...radead.org>, 
	Davidlohr Bueso <dave@...olabs.net>, Ingo Molnar <mingo@...hat.com>, 
	Juri Lelli <juri.lelli@...hat.com>, Peter Zijlstra <peterz@...radead.org>, 
	Thomas Gleixner <tglx@...utronix.de>, Valentin Schneider <vschneid@...hat.com>, 
	Waiman Long <longman@...hat.com>
Subject: Re: [PATCH v5 2/3] man/man2/prctl.2, PR_FUTEX_HASH_SET_SLOTS.2const:
 Document PR_FUTEX_HASH_SET_SLOTS

On Thu, Aug 21, 2025 at 04:08:51PM +0200, Sebastian Andrzej Siewior wrote:
> On 2025-08-19 13:19:15 [+0200], Alejandro Colomar wrote:
> > Hi Sebastian,
> Hi Alejandro,

Hi Sebastian,

> > > > +.B int prctl(PR_FUTEX_HASH, PR_FUTEX_HASH_SET_SLOTS,
> > > > +.BI "          unsigned long " hash_size ", unsigned long " hash_flags ");
> > 
> > I see that it is implemented in the kernel as
> > 
> > 	static int
> > 	futex_hash_allocate(unsigned int hash_slots, unsigned int flags)
> > 	{
> > 		...
> > 	}
> > 
> > But PR_FUTEX_HASH is implemented as
> > 
> > 	int
> > 	futex_hash_prctl(unsigned long arg2, unsigned long arg3,
> > 	    unsigned long arg4)
> > 	{
> > 		...
> > 	}
> > 
> > Should we document is as a u_int, or a u_long?  Is that mismatch a bug,
> > or is it on purpose?
> 
> The prctl() interface is long so I started with that. Internally we keep
> it as an int since we don't need it that big and it avoids a hole
> otherwise (but then there is a hole towards the end of the structure).
> Realistically speaking 1 << 31 is the largest value that can be
> specified (atm) and it will very likely lead to ENOMEM. If the user
> tries the next higher value, 1 << 32, then the upper bits will be
> truncated and the global hash will be requested and this will succeed.
> 
> The bug could be based on the argument type 1 << 32 will succeed but
> it should not. Using 1 << 25 will request ~2GiB of memory and is a bit
> far from sane.
> I am bit forth and back between forcing an error for anything > 1 << 30,
> or updating the docs to int. But this will be the easiest ;)
> Any recommendations based on similar cases?

I don't remember any similar cases atm.

I guess we should document it as long, because in ABIs where it matters,
users should pass a long.  People should probably not be passing such
huge values, so we can leave it as an undocumented bug, which can be
fixed later if we ever find it to be important.

Changing the implementation from int to long if we ever need it should
be easy, as it doesn't break user space (it would rather fix it).


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)