3 ms·

Once I'd finished upgrading my openssh instances (which are linked against musl not glibc) I thought it'd be interesting to have a poke at musl's syslog(3) and

Once I'd finished upgrading my openssh instances (which are linked against musl not glibc) I thought it'd be interesting to have a poke at musl's syslog(3) and see if it allocates too and so is easily exploitable in the same way. But as far as I can see, it doesn't: https://github.com/bminor/musl/blob/master/src/misc/syslog.c https://github.com/bminor/musl/blob/master/src/misc/syslog.c Everything there is either on stack or in static variables protected from reentrancy by the lock. The {d,sn,vsn}printf() calls there don't allocate in musl, although they might in glibc. Have I missed anything here?

singron 2y ago
If you are right about the allocations, then I think the worst it can do is deadlock since the locks aren't recursive. Deadlock in sigalrm could still lead to a DOS since that might prevent it from cleaning up connections.
- mananaysiempre 2y ago
  Heretical opinion: signal handler activations should count as separate threads for the purposes of recursive locking.
  - bhawks 2y ago
    How would be done without introducing deadlock?
    - mananaysiempre 2y ago
      You’d get a deadlock, absolutely. But I’m fine with that: if the thread wants to access some state protected by a mutex, then while holding it (effectively) spawns a signal handler activation and waits for it to complete, and the signal handler tries to accept some state protected by the same mutex, then the program has just deadlocked (mutex → signal handler → mutex) and deserves to hang (or die, as this is a very simple situation as far as deadlock detection goes). That’s in any case better than corrupted state.
- qhwudbebd 2y ago
  Yes, true: if the alarm signal arrives right in the middle of another syslog() call, this should deadlock. (Safer that it not deadlocking and accessing the static state in the signal handler of course!)
qhwudbebd 2y ago
Confirmation from Rich: https://fosstodon.org/@musl/112711796005712271 https://fosstodon.org/@musl/112711796005712271

singron 2y ago

If you are right about the allocations, then I think the worst it can do is deadlock since the locks aren't recursive. Deadlock in sigalrm could still lead to a DOS since that might prevent it from cleaning up connections.

mananaysiempre 2y ago
Heretical opinion: signal handler activations should count as separate threads for the purposes of recursive locking.
- bhawks 2y ago
  How would be done without introducing deadlock?
  - mananaysiempre 2y ago
    You’d get a deadlock, absolutely. But I’m fine with that: if the thread wants to access some state protected by a mutex, then while holding it (effectively) spawns a signal handler activation and waits for it to complete, and the signal handler tries to accept some state protected by the same mutex, then the program has just deadlocked (mutex → signal handler → mutex) and deserves to hang (or die, as this is a very simple situation as far as deadlock detection goes). That’s in any case better than corrupted state.
qhwudbebd 2y ago
Yes, true: if the alarm signal arrives right in the middle of another syslog() call, this should deadlock. (Safer that it not deadlocking and accessing the static state in the signal handler of course!)

qhwudbebd 2y ago

Confirmation from Rich: https://fosstodon.org/@musl/112711796005712271 https://fosstodon.org/@musl/112711796005712271