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: <aEaRpf_sHip9wH3G@vaxr-BM6660-BM6360>
Date: Mon, 9 Jun 2025 15:47:49 +0800
From: I Hsin Cheng <richard120310@...il.com>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
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

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

Hi Thomas,

Thanks for pointing out the problem, may I ask in what config would
cause "BITS_PER_LONG" to work incorrectly ?

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

Best regards,
I Hsin Cheng


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ