[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260922191939.GS23438@brightrain.aerifal.cx>
Date: Tue, 22 Sep 2026 15:19:41 -0400
From: Rich Felker <dalias@...c.org>
To: Ivan Egorov <me@...ri.ch>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: OOB array access in decfloat?
On Tue, Sep 22, 2026 at 06:00:25PM +0000, Ivan Egorov wrote:
> hi folks,
>
> i believe i accidentally came across an out-of-bounds access in `strtod`, or rather in `decfloat` on line 259 of `floatscan.c`:
>
> `if ((a+i & MASK)==z) x[(z=(z+1 & MASK))-1] = 0;`
>
> with z=KMAX-1 this rolls to zero in assignment and to -1 afterwards.
>
> A (Claude-assisted) minimal reproduction, triggering gcc's ASan is
> in the attached .tgz. The test case originates in
> parse-number-fxx-test-data set. I originally found this bug by
> compiling the implementation with tcc 0.9.27 which does not allocate
> stack variables into registers, and hence garbled a neighbor and
> (unlike gcc) returned wrong answer for this test.
For future reference, including the information inline in the email or
at least as an attachment that can be read without extracting a binary
archive would make this a lot more accessible to the community to
easily read.
> A minimal patch (also in the archive):
>
> `if ((a+i & MASK)==z) x[(z=(z+1 & MASK))-1 & MASK] = 0;`
Would you agree that the following also works?
- if ((a+i & MASK)==z) x[(z=(z+1 & MASK))-1] = 0;
+ if ((a+i & MASK)==z) x[z] = 0, z = z+1 & MASK;
I think the source of the problem was trying to be overly clever
mixing the update to z and store to x[old_z] in the same expression.
It was probably a consequence of converting a z++, which would have
done the right thing, to the more complicated form to wrap mod MASK+1
during writing of the code.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
