mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] Large overflow in __intscan ignored
@ 2023-12-01  5:08 Anuraag Agrawal
  2023-12-01  5:14 ` [musl] " Anuraag Agrawal
  2023-12-01 16:21 ` [musl] " Markus Wichmann
  0 siblings, 2 replies; 7+ messages in thread
From: Anuraag Agrawal @ 2023-12-01  5:08 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

Currently, __intscan, used by functions like strtol, does not seem to check
for overflow during multiplication.

https://git.musl-libc.org/cgit/musl/tree/src/internal/intscan.c#n69

It at the end checks against the limit, e.g. the size of a long

https://git.musl-libc.org/cgit/musl/tree/src/internal/intscan.c#n90

However, if the value overflows and ends up in the range of the limit,
errno will not be set. It seems that each multiplication operation needs to
be checking for overflow and return errno if it ever happens.

[-- Attachment #2: Type: text/html, Size: 831 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [musl] Re: Large overflow in __intscan ignored
  2023-12-01  5:08 [musl] Large overflow in __intscan ignored Anuraag Agrawal
@ 2023-12-01  5:14 ` Anuraag Agrawal
  2023-12-01 15:52   ` Rich Felker
  2023-12-01 16:21 ` [musl] " Markus Wichmann
  1 sibling, 1 reply; 7+ messages in thread
From: Anuraag Agrawal @ 2023-12-01  5:14 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

Oops, sorry I should have mentioned, the inputs I am working with that do
not set errno are

999999999999999999999
1000000000000000000000
4790999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999

For context, they come from test cases in libpg_query

https://github.com/pganalyze/libpg_query/blob/15-latest/test/scan_tests.c#L30

On Fri, Dec 1, 2023 at 2:08 PM Anuraag Agrawal <anuraaga@gmail.com> wrote:

> Currently, __intscan, used by functions like strtol, does not seem to
> check for overflow during multiplication.
>
> https://git.musl-libc.org/cgit/musl/tree/src/internal/intscan.c#n69
>
> It at the end checks against the limit, e.g. the size of a long
>
> https://git.musl-libc.org/cgit/musl/tree/src/internal/intscan.c#n90
>
> However, if the value overflows and ends up in the range of the limit,
> errno will not be set. It seems that each multiplication operation needs to
> be checking for overflow and return errno if it ever happens.
>
>

[-- Attachment #2: Type: text/html, Size: 1884 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Re: Large overflow in __intscan ignored
  2023-12-01  5:14 ` [musl] " Anuraag Agrawal
@ 2023-12-01 15:52   ` Rich Felker
  0 siblings, 0 replies; 7+ messages in thread
From: Rich Felker @ 2023-12-01 15:52 UTC (permalink / raw)
  To: Anuraag Agrawal; +Cc: musl

On Fri, Dec 01, 2023 at 02:14:03PM +0900, Anuraag Agrawal wrote:
> Oops, sorry I should have mentioned, the inputs I am working with that do
> not set errno are
> 
> 999999999999999999999
> 1000000000000000000000
> 4790999999999999999999999999999999999999999999999999999999999999999999999999999999999999
> 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
> 
> For context, they come from test cases in libpg_query
> 
> https://github.com/pganalyze/libpg_query/blob/15-latest/test/scan_tests.c#L30
> 
> On Fri, Dec 1, 2023 at 2:08 PM Anuraag Agrawal <anuraaga@gmail.com> wrote:
> 
> > Currently, __intscan, used by functions like strtol, does not seem to
> > check for overflow during multiplication.
> >
> > https://git.musl-libc.org/cgit/musl/tree/src/internal/intscan.c#n69
> >
> > It at the end checks against the limit, e.g. the size of a long
> >
> > https://git.musl-libc.org/cgit/musl/tree/src/internal/intscan.c#n90
> >
> > However, if the value overflows and ends up in the range of the limit,
> > errno will not be set. It seems that each multiplication operation needs to
> > be checking for overflow and return errno if it ever happens.

Can you clarify whether you are reporting a bug in musl or trying to
reuse this code and possibly making breaking changes to your copy? I
cannot reproduce any problem with your test cases. They all correctly
report ERANGE. Checked for strtol, strtoll, and strtoull.

Rich

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Large overflow in __intscan ignored
  2023-12-01  5:08 [musl] Large overflow in __intscan ignored Anuraag Agrawal
  2023-12-01  5:14 ` [musl] " Anuraag Agrawal
@ 2023-12-01 16:21 ` Markus Wichmann
  2023-12-02  1:42   ` Anuraag Agrawal
  1 sibling, 1 reply; 7+ messages in thread
From: Markus Wichmann @ 2023-12-01 16:21 UTC (permalink / raw)
  To: musl; +Cc: Anuraag Agrawal

Am Fri, Dec 01, 2023 at 02:08:54PM +0900 schrieb Anuraag Agrawal:
> Currently, __intscan, used by functions like strtol, does not seem to check
> for overflow during multiplication.
>
> https://git.musl-libc.org/cgit/musl/tree/src/internal/intscan.c#n69
>

There is no multiplication in the referenced line. Assuming you mean the
one above it, the loop condition checks that neither the multiplication
nor the addition can overflow. The same holds for the loop on lines 79f.

As far as I can tell, this has been the case since the first version of
this code was checked in in 2012.

Ciao,
Markus

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Large overflow in __intscan ignored
  2023-12-01 16:21 ` [musl] " Markus Wichmann
@ 2023-12-02  1:42   ` Anuraag Agrawal
  2023-12-02  8:48     ` Markus Wichmann
  0 siblings, 1 reply; 7+ messages in thread
From: Anuraag Agrawal @ 2023-12-02  1:42 UTC (permalink / raw)
  To: Markus Wichmann; +Cc: musl

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

Hello,

Thanks for checking and very sorry for the noise, I didn't read the loop
condition correctly. I am using Webassembly so the issue must be specific
to it somehow. I will report on wasi-libc to follow up.

Thanks,

On Sat, Dec 2, 2023, 01:21 Markus Wichmann <nullplan@gmx.net> wrote:

> Am Fri, Dec 01, 2023 at 02:08:54PM +0900 schrieb Anuraag Agrawal:
> > Currently, __intscan, used by functions like strtol, does not seem to
> check
> > for overflow during multiplication.
> >
> > https://git.musl-libc.org/cgit/musl/tree/src/internal/intscan.c#n69
> >
>
> There is no multiplication in the referenced line. Assuming you mean the
> one above it, the loop condition checks that neither the multiplication
> nor the addition can overflow. The same holds for the loop on lines 79f.
>
> As far as I can tell, this has been the case since the first version of
> this code was checked in in 2012.
>
> Ciao,
> Markus
>

[-- Attachment #2: Type: text/html, Size: 1462 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Large overflow in __intscan ignored
  2023-12-02  1:42   ` Anuraag Agrawal
@ 2023-12-02  8:48     ` Markus Wichmann
  2023-12-02 16:29       ` Rich Felker
  0 siblings, 1 reply; 7+ messages in thread
From: Markus Wichmann @ 2023-12-02  8:48 UTC (permalink / raw)
  To: musl; +Cc: Anuraag Agrawal

Am Sat, Dec 02, 2023 at 10:42:11AM +0900 schrieb Anuraag Agrawal:
> Hello,
>
> Thanks for checking and very sorry for the noise, I didn't read the loop
> condition correctly. I am using Webassembly so the issue must be specific
> to it somehow. I will report on wasi-libc to follow up.
>
> Thanks,

Don't worry about it. The only way I see this could overflow is if
ULLONG_MAX is not the correct limit for what the compiler implements as
"unsigned long long". Though I don't see how that could be, since musl
defines ULLONG_MAX as the minimum value the type can have according to
the C standard.

Or else, of course, maybe the compiler's implementation of 64-bit
multiplication is broken.

Ciao,
Markus

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Large overflow in __intscan ignored
  2023-12-02  8:48     ` Markus Wichmann
@ 2023-12-02 16:29       ` Rich Felker
  0 siblings, 0 replies; 7+ messages in thread
From: Rich Felker @ 2023-12-02 16:29 UTC (permalink / raw)
  To: Markus Wichmann; +Cc: musl, Anuraag Agrawal

On Sat, Dec 02, 2023 at 09:48:58AM +0100, Markus Wichmann wrote:
> Am Sat, Dec 02, 2023 at 10:42:11AM +0900 schrieb Anuraag Agrawal:
> > Hello,
> >
> > Thanks for checking and very sorry for the noise, I didn't read the loop
> > condition correctly. I am using Webassembly so the issue must be specific
> > to it somehow. I will report on wasi-libc to follow up.
> >
> > Thanks,
> 
> Don't worry about it. The only way I see this could overflow is if
> ULLONG_MAX is not the correct limit for what the compiler implements as
> "unsigned long long". Though I don't see how that could be, since musl
> defines ULLONG_MAX as the minimum value the type can have according to
> the C standard.
> 
> Or else, of course, maybe the compiler's implementation of 64-bit
> multiplication is broken.

Ouch, sounds like this is going to be some sort of big wasm bug...

Rich

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2023-12-02 16:29 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-01  5:08 [musl] Large overflow in __intscan ignored Anuraag Agrawal
2023-12-01  5:14 ` [musl] " Anuraag Agrawal
2023-12-01 15:52   ` Rich Felker
2023-12-01 16:21 ` [musl] " Markus Wichmann
2023-12-02  1:42   ` Anuraag Agrawal
2023-12-02  8:48     ` Markus Wichmann
2023-12-02 16:29       ` Rich Felker

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).