Bug 112617
Summary: | array bounds error in byacc | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Steve Dum <steve_dum> |
Component: | byacc | Assignee: | Petr Machata <pmachata> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1 | CC: | dickey, mattdm, mnewsome |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-10-25 20:26:39 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: |
I've applied this to my version, will be on ftp area tomorrow. Is there a testcase that you could provide, please? Not any longer. That was a different job. Sorry Fedora Core 1 is maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thanks! NOTE: Fedora Core 1 is reaching the final end of support even by the Legacy project. After Fedora Core 6 Test 2 is released (currently scheduled for July 26th), there will be no more security updates for FC1. Please use these next two weeks to upgrade any remaining FC1 systems to a current release. Closing per previous comment and lack of response. Also note that FC1 and FC2 are no longer supported even by Fedora Legacy. |
Description of problem: certian grammars can cause byacc to attempt to access data off the end of a malloced array. Version-Release number of selected component (if applicable):1.9 How reproducible:always - grammar dependent. Steps to Reproduce: in end_rule() reader.c when a rule is bugun (reader encounters the : of the rule) end_rule() is called. It makes a check to see if this rule returns a value and if a value is available to return. However, if we are at the start of a new rule, the last thing on the pitem stack is a null. If it happens that this item is also the 300'th item on the stack (or a multiple of 300) the loop erroneously thinks it is at the start of a rule with data following and tries to access the 301'st element exceeding the array limits. It appears that the simplest solution is that end_rule can just check if the last element is a null and skip this check for a missing default action since the default action hasn't been entered yet. 1106,1110c1106,1108 < if (pitem[nitems-1]) { < for (i = nitems - 1; pitem[i]; --i) continue; < if (pitem[i+1] == 0 || pitem[i+1]->tag != plhs[nrules]->tag) < default_action_warning(); < } --- > for (i = nitems - 1; pitem[i]; --i) continue; > if (pitem[i+1] == 0 || pitem[i+1]->tag != plhs[nrules]->tag) > default_action_warning(); Solution is in the diff above.