This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/2] Parse hex and octal strings correctly in __strtoul_internal


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]