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)

x86
All
defect
Not set
normal

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.
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?
Whiteboard: sg:?
Whiteboard: sg:? → [sg:?]
Component: XPCOM Registry → XPCOM
Whiteboard: [sg:?]
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.