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: <20250610091238-51888002-5c91-4716-b3bc-f6bd28cbee61@linutronix.de>
Date: Tue, 10 Jun 2025 09:19:48 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: I Hsin Cheng <richard120310@...il.com>
Cc: Yury Norov <yury.norov@...il.com>, linux-kernel@...r.kernel.org, 
	stable@...r.kernel.org
Subject: Re: [PATCH] uapi: bitops: use UAPI-safe variant of BITS_PER_LONG
 again

Hi I Hsin Cheng,

On Mon, Jun 09, 2025 at 03:47:49PM +0800, I Hsin Cheng wrote:
> On Fri, Jun 06, 2025 at 04:32:22PM +0200, Thomas Weißschuh wrote:
> > On Fri, Jun 06, 2025 at 10:20:56AM -0400, Yury Norov wrote:
> > > On Fri, Jun 06, 2025 at 10:23:57AM +0200, Thomas Weißschuh wrote:
> > > > Commit 1e7933a575ed ("uapi: Revert "bitops: avoid integer overflow in GENMASK(_ULL)"")
> > > > did not take in account that the usage of BITS_PER_LONG in __GENMASK() was
> > > > changed to __BITS_PER_LONG for UAPI-safety in
> > > > commit 3c7a8e190bc5 ("uapi: introduce uapi-friendly macros for GENMASK").
> > > > BITS_PER_LONG can not be used in UAPI headers as it derives from the kernel
> > > > configuration and not from the current compiler invocation.
> > > > When building compat userspace code or a compat vDSO its value will be
> > > > incorrect.
> > > > 
> > > > Switch back to __BITS_PER_LONG.
> > > > 
> > > > Fixes: 1e7933a575ed ("uapi: Revert "bitops: avoid integer overflow in GENMASK(_ULL)"")
> > > > Cc: stable@...r.kernel.org
> > > > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> > > 
> > > Thanks Thomas. I applied it in bitmap-for-next. Is that issue critical
> > > enough for you to send a pull request in -rc2?
> > 
> > I have some patches that depend on it. These will probably end up in linux-next
> > soonish and would then break there.
> > 
> > So having it in -rc2 would be nice.
> 
> Thanks for pointing out the problem, may I ask in what config would
> cause "BITS_PER_LONG" to work incorrectly ?

In my specific usecase it was when building the powerpc compat vDSO.
For an easy reproducer use:

diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c
index 93ef801a97ef..948619848a3b 100644
--- a/lib/vdso/gettimeofday.c
+++ b/lib/vdso/gettimeofday.c
@@ -16,6 +16,9 @@
 # define VDSO_DELTA_MASK(vd)   (vd->mask)
 #endif
 
+_Static_assert(__BITS_PER_LONG == sizeof(long) * 8);
+_Static_assert(BITS_PER_LONG == sizeof(long) * 8);
+
 #ifdef CONFIG_GENERIC_VDSO_OVERFLOW_PROTECT
 static __always_inline bool vdso_delta_ok(const struct vdso_clock *vc, u64 delta)
 {

> I would love to test the difference between them and see what I can get,
> thanks.

Looking at this again, the UAPI headers don't even define BITS_PER_LONG.
The vDSO just incorrectly ends up also using the regular kernel headers.


Thomas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ