A null pointer dereference vulnerability was found in function _xrealloc() in xlsp_xmalloc.c in OpenSLP. A remote attacker could potentially crash the server when large number of packets are sent.
void * _xrealloc(const char * file, int line, void * ptr, size_t size)
xallocation_t * x;
return _xmalloc(file, line, size);
_xfree(file, line, ptr);
x = _xmalloc_find(ptr);
if (x != 0)
void * newptr = ptr;
if (x->size != size)
newptr = _xmalloc(file, line, size); //*** return 0 if failed from _xmalloc
memcpy(newptr, ptr, x->size); //*** it'll cased a null pointer reference
_xfree(file, line, x);
fprintf(G_xmalloc_fh, "*** xrealloc called on "
"non-xmalloc'd memory ***\n");
Name: Yuguang Cai (Qihoo 360)
CVE request at:
Created openslp tracking bugs for this issue:
Affects: fedora-all [bug 1337402]
Affects: epel-5 [bug 1337403]
Upstream has been made aware of this issue via:
Curious, why was this closed->WONTFIX ?
openslp-2.0.0-9.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
openslp-2.0.0-6.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
openslp-2.0.0-8.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Please note that the function in question - _xmalloc (recently changed to slp_xmalloc for libslp namespace reasons) is a DEBUG-only method. That is, it is only implemented in DEBUG builds of OpenSLP. Given this fact, it's unlikely to be a security issue in any deployment.
Sorry - I meant _xrealloc (now slp_xrealloc).
I've fixed the issue in openslp mercurial commit 1781.