linux-hardening - Re: [PATCH v6 1/5] lib: fix _parse_integer

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: <20260212132517.1ac5de44@pumpkin>
Date: Thu, 12 Feb 2026 13:25:17 +0000
From: David Laight <david.laight.linux@...il.com>
To: Dmitry Antipov <dmantipov@...dex.ru>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>, Andrew Morton
 <akpm@...ux-foundation.org>, Kees Cook <kees@...nel.org>,
 <djwong@...nel.org>, linux-hardening@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 1/5] lib: fix _parse_integer_limit() to handle
 overflow

On Thu, 12 Feb 2026 12:00:30 +0000
David Laight <david.laight.linux@...il.com> wrote:

Re-send with "..." removed from one of the addresses so my MUA (claws) won't
escape the second one and the list-servers fail to accept the mail.

> On Thu, 12 Feb 2026 14:13:16 +0300
> Dmitry Antipov <dmantipov@...dex.ru> wrote:
> 
> > On Tue, 2026-02-10 at 09:36 +0200, Andy Shevchenko wrote:
> >   
> > > I don't see how max_chars is used. With that said, I would rather see the usual
> > > way of expressing the condition in the for-loop:
> > > 
> > > 	for (rv = 0; rv < max_chars; rv++, s++) {    
> > 
> > This will break the loop (and so stop consuming characters) if KSTRTOX_OVERFLOW
> > bit is set.
> >   
> > > > +		if (likely(res != ULLONG_MAX)) {    
> > > 
> > > Have you seen David's question about these checks?
> > > Maybe I missed your answer...  
> 
> I've not seen one...
> 
> > >     
> > > > +			if (unlikely(res & (~0ull << 60))) {    
> > 
> > The first check may be dropped indeed (assuming check_mul_overflow(ULLONG_MAX, a, b)
> > and check_add_overflow(ULLONG_MAX, a, b) always signals an overflow).  
> 
> That check for the high bits may well be cheaper than the one in
> check_mul_overflow() - which is likely to need to partially generate
> the 128bit result.
> Also if the code is going to call check_mul_overflow() it ought to use the
> result in the 'non-overflow' case.
> 
> But there is nothing 'magic' about check_mul_overflow(), given the base
> is known (and the only dificult one is 10) comparing against the known
> limit will be better code.
> 
> 	David
> 
> 
> > 
> > Dmitry  
>