Opening many connections to lircd can cause a buffer overflow. So far I did not think about any explit. For me it just resulted in a segfault. The problem is that the number of client connections is limited only by the file descriptor numbers, but the reserved buffer space is a little bit less than the maximum allowed file descriptor. The actual overflow happenes when using clin as an array index. I report this bug upstream at the same time, so I'd expect it to be fixed rather soon, but you never know for sure, and I want Gentoo to be one step ahead.
Created attachment 80426 [details, diff] patch to lircd.c to avoid buffer overflow
Setting to Auditing for validation
Auditing any news on this one?
It certainly looks like a bug, adding maintainer to help determine impact. Matthias, the patch looks good, is there any security impact here? If not please consider applying the patch.
My patch plus a set of parenthesis around the constant definition has been committed to the upstream CVS on Feb 28 for revision 5.63 of lircd.c. http://lirc.cvs.sourceforge.net/lirc/lirc/daemons/lircd.c?r1=5.62&r2=5.63 lirc dev Christoph Bartelmus saw no security impact, as the overflow occurs on the heap not the stack, and there is no user input, so an exploit is unlikely. I guess that my strict access restriction to this bug report here might have caused this slow procedure in addressing the issue. Sorry there.
Okay, thanks for the update Martin. Reassigning to maintainer, who can apply the patch to our package if nescessary.
Solved in lirc-0.8.0-r7, thanks for the patch.
