Bug 145997
| Summary: | hexadecimal integers in user options not accepted | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Steve Friedman <steve> | ||||
| Component: | dhcp | Assignee: | Jason Vas Dias <jvdias> | ||||
| Status: | CLOSED ERRATA | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3 | CC: | sundaram | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2005-09-05 08:24:59 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 170773, 170776 | ||||||
| Attachments: |
|
||||||
Thanks for reporting this bug - I'll develop a fix for Red Hat FC4 + FC3 and submit it to the ISC ASAP . Shortly after I submitted this to bugzilla, I got the following
response on the DHCP mailing list:
Steve; dhcp-bugs is our bug tracking system. I saw you asked
about this on the mailing list, so I opened a ticket and placed you as
requestor.
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.
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: http://people.redhat.com/~jvdias/DHCP/FC2 http://people.redhat.com/~jvdias/DHCP/FC2/3.0.2rc3 Created attachment 110152 [details]
patch to common/parse.c fixing hex integer user defined option parse
Correction to Comment #3: http://people.redhat.com/~jvdias/DHCP/FC2/3.0.2rc3 should have been: http://people.redhat.com/~jvdias/DHCP/FC3/3.0.2rc3 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. 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. Yes, I can confirm that my specific problem has been resolved. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040808 Firefox/0.9.3 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 number". Example: 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): dhcp-3.0.1-11 How reproducible: Always 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" 3. 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.