Dropbear processes getting into uninterruptible I/O process "D" state

[Geoff Winkless]

On Tue, 15 Oct 2019 at 15:30, Matt Johnston <matt at ucc.asn.au> wrote:
> I think regardless of what Dropbear's doing with pipes (closed sessions etc), there is probably something wrong with the Linux kernel.
> As far as I know userspace can't trigger D state even intentionally (I'd be interested if anyone knows a way though).
> -K is unrelated, that just sends some SSH traffic at a certain interval.

Apologies for dropping in on an old thread, not sure if this is still
a problem, but I came across something similar with some of my own
code and remembered this thread so figured I'd add the result of what
I found there in case it was helpful (probably not, but you never
know...)

Linux puts vfork()'s parents into the D state until the child returns:
as a result if you vfork() and then fail to exec() (or more likely if
the exec() call fails) without _exit() in the child Linux will leave
the parent in D state permanently until the child quits.

Is DROPBEAR_VFORK enabled on the example build for some reason? It
shouldn't be - as far as I can tell HAVE_FORK should always be true on
Linux, but I guess it could be incorrectly configured somehow.

Test code:

#include <unistd.h>
#include <stdio.h>

int main (int argc, char **argv) {
  char buff[1024];
  if (vfork()==0) { // child process
    sprintf(buff, "ps auxww | grep %s", argv[0]);
    system(buff); // shows D process
    execl("/bin/invalidbinary", "invalidbinary", NULL);
  // note no _exit() call
  }
// if you do stuff here, the child will take over, while the parent is
stuck in D
}

Now it's not immediately obvious how this would happen in the dropbear
code, although I might be missing something obvious, but it's one very
easy way to get a D state process on Linux.

Geoff