The following appear to be minor issues, not leading to crashes or worse (at most information disclosure due to limited buffer over-reading).
__pmGetPDU should enforce minimum PDU lengths, based on a table of per-type minimum values. This way, individual length checks won't have to be added to decoding functions for constant-size PDUs (such as __pmDecodeLogStatus, __pmDecodeTextReq, __pmDecodeError).
__pmDecodeTextReq should initialize *ident in all cases.
__pmEncodeResult seems to produce vlen fields for non-PM_VAL_INSITU values which are too large in some cases. Truncating strings at the first NUL byte during decoding appears to hide this. This is visible with proc.psinfo.cmd, for instance.
Somehow, I only just came across this bugzilla entry today.
There are three issues here: for the first, we went the other way to Florian's table-based suggestion (i.e. checking sizes in individual handlers). So that went out with 3.6.5, but spread across the many individual patches for each PDU type.
For the second issue, related to *ident not being initialized, that is fixed by the patch coming shortly. Its minor though, can't see anything exposed there, will go into pcp-3.6.6.
I'll have to look a bit deeper into the result encoding issue and report back later.
assigned to nathan (this one fell thru the cracks), but all seem to agree the
security implications are not severe.
Created attachment 604783 [details]
Ensure ident is always initialized in text PDU decoder
Resolves the missing case where ident could be returned without initialisation, and with a return code indicating success in __pmDecodeText.
OK, I understand the third case now. The encode function is a bit misleading - it contains code that is marked #ifdef PCP_DEBUG, that initialises the parts of the buffer which I think Florian is calling out here. It turns out that in all builds of PCP, this "debug" macro is always set. So these parts of the passed out buffer are in fact initialised (with "~" character) after all, always.
I believe the patch I posted earlier is all we will need for this issue now, and I concur fully with Florian's assessment of these ones being minor issues that are not critical to push immediately. The patch I posted earlier will go with the pcp-3.6.6 release, which will likely happen with the next two weeks.
Upstream commit (dev branch):
This patch will be a part of pcp-3.6.6
pcp-3.6.6-1.fc16 has been submitted as an update for Fedora 16.
pcp-3.6.6-1.fc17 has been submitted as an update for Fedora 17.
pcp-3.6.6-1.el5 has been submitted as an update for Fedora EPEL 5.
pcp-3.6.6-1.fc18 has been submitted as an update for Fedora 18.
pcp-3.6.6-1.el6 has been submitted as an update for Fedora EPEL 6.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing pcp-3.6.6-1.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Bugzilla maint - this issue has been resolved in Fedora for awhile.
pcp-3.6.6-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.6.8-1.fc16 has been submitted as an update for Fedora 16.
pcp-3.6.8-1.fc17 has been submitted as an update for Fedora 17.
pcp-3.6.9-1.el5 has been submitted as an update for Fedora EPEL 5.
pcp-3.6.9-1.fc18 has been submitted as an update for Fedora 18.
pcp-3.6.9-1.fc16 has been submitted as an update for Fedora 16.
pcp-3.6.9-1.el6 has been submitted as an update for Fedora EPEL 6.
pcp-3.6.9-1.fc17 has been submitted as an update for Fedora 17.