Bug 170776 - hexadecimal integers in user options not accepted
hexadecimal integers in user options not accepted
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: dhcp (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Depends On: 145997
Blocks: 168429
  Show dependency treegraph
Reported: 2005-10-14 11:09 EDT by Jason Vas Dias
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2006-0114
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-07 13:15:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0114 qe-ready SHIPPED_LIVE dhcp bug fix update 2006-03-06 00:00:00 EST

  None (edit)
Description Jason Vas Dias 2005-10-14 11:09:11 EDT
+++ This bug was initially created as a clone of Bug #145997 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040808

Description of problem:
There is a bug in parsing unsigned integers in (amongst other places) user
option.  If I set the value of the option                                      
                           to a hexadecimal number that happens to only contain
digits from 0-9, it                                                            
  works (the client gets the option with the correct value).  However, if I    
                                                           include the
hexadecimal digits from A-F (or a-f), it fails with "expecting                 

option ADSI.blah code 3 = unsigned integer 32;                        
option ADSI.blah  0x4100123;    # works --> hex value 
option ADSI.blah 0x4100ABC;     # doesn't work; get expecting number

From reading the code it seems that get_token() is returning NUMBER_OR_NAME and
either the caller, get_token, or read_number isn't clever enough to realize that
(in this case) it is a NUMBER.  I don't know the program flow well enough to
know the best location to patch the problem.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Set an option to a value of 0x1234.  The parser completes as expected.
2. Set an option to a value of 0xabcd.  The parser fails with "expecting number"

Actual Results:  The parser fails with "expecting number".

Expected Results:  Recognized that 0xabcd is a number and parsed correctly.

Additional info:

I verified this bug in dhcp-3.0.2rc3, and reported it on the dhcp mailing list,
but haven't received any indication that it will be fixed.

-- Additional comment from jvdias@redhat.com on 2005-01-24 12:04 EST --
Thanks for reporting this bug - I'll develop a fix for Red Hat 
FC4 + FC3 and submit it to the ISC ASAP .

-- Additional comment from steve@adsi-m4.com on 2005-01-24 13:02 EST --
Shortly after I submitted this to bugzilla, I got the following
response on the DHCP mailing list:

Steve; dhcp-bugs@isc.org is our bug tracking system.  I saw you asked
about this on the mailing list, so I opened a ticket and placed you as
This bug looks pretty straightforward; a simple misunderstanding     
between NUMBER and NUMBER_OR_NAME tokens.  We should be able to fix  
this in the next maintenance release. 

-- Additional comment from jvdias@redhat.com on 2005-01-24 14:49 EST --
This bug is now fixed in FC4/Rawhide (see attached patch) and I've
compiled it for FC2 and FC3 - you can download it from:

-- Additional comment from jvdias@redhat.com on 2005-01-24 14:50 EST --
Created an attachment (id=110152)
patch to common/parse.c fixing hex integer user defined option parse

-- Additional comment from jvdias@redhat.com on 2005-01-24 15:08 EST --
Correction to Comment #3:
should have been:

-- Additional comment from steve@adsi-m4.com on 2005-01-26 18:03 EST --
I am confused by the patch.  It appears to only fix the problem that I
reported.  However, a quick grep of the dhcp-3.0.2rc3 codebase shows 7
locations (3 in common/parse.c and 4 in server/confparse.c) that check
for NUMBER to the exclusion of NUMBER_OR_NAME.  Likewise, checking for
NAME shows that common/parse.c always checks for NAME or
NUMBER_OR_NAME; however, one time in server/confparse.c it checks for
both and one time it only checks for NAME.  It seems to me that these
other matches should be changed as well to fix analogous, latent bugs.

-- Additional comment from jvdias@redhat.com on 2005-01-26 18:17 EST --
Yes, not every integer option may be specified in hex;
also we don't allow hex IP address octets.
The patch only allows user defined integer options to be
specified in hex.
The ISC DHCP developer recognizes the problem and is working
on a more general purpose fix for the next DHCP maintenance release;
when this comes out, it will be integrated with the Red Hat release.
Meanwhile, the patch does fix your specific problem.

-- Additional comment from steve@adsi-m4.com on 2005-01-26 18:23 EST --
Yes, I can confirm that my specific problem has been resolved.
Comment 1 Jason Vas Dias 2005-10-14 11:10:13 EDT
fixed with dhcp-3.0.1-40_EL4+
Comment 7 Red Hat Bugzilla 2006-03-07 13:15:02 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.