Glibc change exposing bugs [LWN.net]

Glibc change exposing bugs

Posted Nov 12, 2010 9:09 UTC (Fri) by dafid_b (guest, #67424)
In reply to: Glibc change exposing bugs by cmccabe
Parent article: Glibc change exposing bugs

Thanks for the code review, much appreciated.

Is syslog() safe to call at this point?
It generates formatted output, which seems like it could itself call memcpy() or do other stuff in te library that the app did not allow for in its plan when it called memcpy.
Also is the system call that sends the message to the log safe, or can it have side effect such as signals and new error codes in errno?

I would be very happy if the answer to the above is: syslog() safe to call like this with no side-effects.

(Log in to post comments)

Glibc change exposing bugs

Posted Nov 13, 2010 3:02 UTC (Sat) by cmccabe (guest, #60281) [Link]

> Is syslog() safe to call at this point?
> It generates formatted output, which seems like it could itself call
> memcpy() or do other stuff in te library that the app did not allow for in
> its plan when it called memcpy

You raise a good issue. glibc's version of syslog is known to call malloc sometimes, which means that you shouldn't use it from within a signal handler. Surprisingly, memcpy isn't on the official list of "async-signal safe" functions, so you could argue that such an implementation would be POSIX conforming :)

But seriously. I think the best thing to do is probably implement your own version of syslog with no memory allocations or calls to memcpy. It's pretty easy to do in a few hundred lines. I had to do it before when writing a good signal handler.