Closed
Bug 329661
Opened 19 years ago
Closed 14 years ago
Possible null pointer dereferences in libreg/src/VerReg.c & libreg/standalone/VerReg.c
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: kherron+mozilla, Unassigned)
References
()
Details
These were found by Coverity; see the URL. Users have to sign up to access their mozilla scans.
Refer to <http://lxr.mozilla.org/seamonkey/source/modules/libreg/src/VerReg.c#1357>. At line 1357, |regPackageName| is tested for NULL meaning it might be NULL. At line 1363, it's passed to |XP_STRLEN()|, which is normally |strlen()|. Strlen() isn't guaranteed to to check its argument for NULL. [Also note the allocation at line 1364 may return non-null even for a 0-length allocation.] Then at line 1367, |regPackageName| is passed to |vr_GetUninstallItemPath| which always derefences the pointer.
The same pattern appears at line 1449 and 1500.
A similar pattern occurs at lines 1617-1629, 1683-1692, and 1740-1749 with the variable |component_path|, |XP_STRLEN|, and |vr_convertPackageName|.
Similar patterns appear in libreg/standalone/VerReg.c beginning at lines 1357, 1449, 1500, 1617, 1683, and 1740.
Setting the security flag just to be super-careful.
Comment 1•17 years ago
|
||
hi kenneth,
any updates on a fix for this? do you know current status of the coverity scan analysis in general, or who else might know?
Updated•17 years ago
|
Whiteboard: sg:?
Updated•17 years ago
|
Whiteboard: sg:? → [sg:?]
Updated•14 years ago
|
Whiteboard: [sg:?]
Comment 2•14 years ago
|
||
This doesn't touch untrusted data and is mostly-gone anyway, WONTFIX.
Group: core-security
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•