|Summary:||slpd crashes if slptool findsrvtypes is run, when message logging is on|
|Product:||[Fedora] Fedora||Reporter:||Paul Flo Williams <paul>|
|Component:||openslp||Assignee:||Rex Dieter <rdieter>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||1.2.1-14.fc11||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-10-02 05:06:16 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Paul Flo Williams 2009-09-16 06:53:38 UTC
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/2009061118 Fedora/3.0.11-1.fc9 Firefox/3.0.11 If "slptool findsrvtypes" is run without specifying the optional "authority" parameter, slpd will segfault while logging the contents of the message. Message logging is turned off by default. Reproducible: Always Steps to Reproduce: 1. Configure slpd to log messages by uncommenting the line for net.slp.traceMsg in /etc/slp.conf. 2. Start the slpd service 3. Type "slptool findsrvtypes" in a terminal. Actual Results: slpd segfaults after logging the standard message header to /var/log/slpd.log, but before showing the fields specific to message type SRVTYPERQST. Expected Results: The message log should be complete and slpd keeps running. Taking a look at slpd/slpd_log.c, I see that SLPDLogSrvTypeRqstMessage() will call SLPDLogBuffer(" namingauth = ", srvtyperqst->namingauthlen, srvtyperqst->namingauth); unconditionally. However, if no authority is provided, namingauth is a null pointer and namingauthlen is 65535, the magic value that means "all naming authorities". A quick test shows that namingauth will also be null if an empty naming authority is provided as well, and namingauthlen will be zero.
Comment 1 Paul Flo Williams 2009-09-16 07:13:24 UTC
Created attachment 361196 [details] Patch to log srvtyperequest properly and protect against other null pointers This patch works for me on F11, and should also apply for EPEL. I submitted this bug report upstream (to the openslp-devel list) on 2009-09-15, but I'm told this is already patched in trunk, which I assume means 1.3.x. I can't get to CVS to check this at the moment.
Comment 2 Rex Dieter 2009-09-16 12:29:41 UTC
thanks, I'll take a look.
Comment 3 Rex Dieter 2009-09-16 13:14:11 UTC
Patch looks good, tests out ok here.
Comment 4 Fedora Update System 2009-09-16 13:31:49 UTC
openslp-1.2.1-14.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/openslp-1.2.1-14.fc11
Comment 5 Fedora Update System 2009-09-16 13:49:52 UTC
openslp-1.2.1-14.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/openslp-1.2.1-14.el5
Comment 6 Fedora Update System 2009-09-17 02:30:41 UTC
openslp-1.2.1-14.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update openslp'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/EL-5/FEDORA-EPEL-2009-0458
Comment 7 Fedora Update System 2009-09-19 00:05:23 UTC
openslp-1.2.1-14.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update openslp'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9703
Comment 8 Fedora Update System 2009-10-02 05:06:09 UTC
openslp-1.2.1-14.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
Comment 9 Fedora Update System 2009-10-03 19:03:53 UTC
openslp-1.2.1-14.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.