[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250725205522.GI1827@brightrain.aerifal.cx>
Date: Fri, 25 Jul 2025 16:55:23 -0400
From: Rich Felker <dalias@...c.org>
To: Thorsten Glaser <tg@...bsd.de>
Cc: musl@...ts.openwall.com
Subject: Re: Bug in IN6_IS_ADDR_V4COMPAT macro for addresses ending in
.1
On Fri, Jul 25, 2025 at 04:35:59PM +0200, Thorsten Glaser wrote:
> On Fri, 25 Jul 2025, Yusuke Endoh wrote:
>
> >I suspect the condition in the macro is incorrect.
> >Currently it checks if the LSB is "> 1", but it should be ">= 1".
>
> The analysis is correct, the fix is wrong (::172.17.1.0 would still
> be misrecognised).
>
> AIUI, the macro needs to check that the address begins with quite a
> lot of zeroes but is not exactly ::1 (or ::).
>
> > #define IN6_IS_ADDR_V4COMPAT(a) \
> > (((uint32_t *) (a))[0] == 0 && ((uint32_t *) (a))[1] == 0 && \
> >- ((uint32_t *) (a))[2] == 0 && ((uint8_t *) (a))[15] > 1)
> >+ ((uint32_t *) (a))[2] == 0 && ((uint8_t *) (a))[15] >= 1)
>
> Is that casting well-defined?
Probably thanks to unions, but maybe not. In any case see the thread
by Brad House, [PATCH 1/1] IN6_IS_ADDR_LOOPBACK() and similar macros
warn on -Wcast-qual. It has a pending patch to do away with this mess
of dubious correctness that I was about to apply, but I see the bug
mentioned here is still present.
> If so, perhaps:
>
> + ((uint32_t *) (a))[2] == 0 && ((uint32_t *) (a))[3] > 1)
>
> Untested, and I’ve not yet had enough coffee, so DWIM ☻
This is not valid, You can't do order comparisons on the uint32_t
units because they're byte order dependent. But I suspect the actual
intent is not >1 but !=0.
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.
