This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] Parse hex and octal strings correctly in __strtoul_internal
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 19 Apr 2012 21:18:49 -0700
- Subject: Re: [PATCH 1/2] Parse hex and octal strings correctly in __strtoul_internal
- References: <20120419115357.658f3bfa@spoyarek>
On Wed, Apr 18, 2012 at 11:23 PM, Siddhesh Poyarekar
<siddhesh@redhat.com> wrote:
> The current implementation of __strtoul_internal seems to only pretend
> to support hex and octal strings by detecting a preceding 0x or 0 and
> marking base as 8 or 16. When it comes to the actual processing of the
> string, it only considers numeric values within, thus breaking hex
> values that may have [a-f] in them. It looks like hexadecimal numbers
> were never parsed in the linker anywhere and hence it got away with
> this.
I see that __strtoul_internal() may be used to parse user-supplied
data, e.g. in elf/rtld.c:
case 10:
/* Mask for the important hardware capabilities. */
if (memcmp (envline, "HWCAP_MASK", 10) == 0)
GLRO(dl_hwcap_mask) = __strtoul_internal (&envline[11], NULL,
0, 0);
> Attached patch adds validation for hexadecimal and octal values since
> the next patch [2/2] looks to use this to parse hexadecimal numbers.
> The test suite reports no regressions and the only place where the hex
> logic is tested, i.e. [patch 2/2] works corectly with this fix.
As far as I can tell, the patch handles 0xabcdef, but not 0xABCDEF.
Please consider handling either case; not doing that is sure to
surprise somebody down the line.
Thanks,
--
Paul Pluzhnikov