#9 sshpass 1.0.5 leads to kernel panic / crashes os x

[MADE/YOUR/DAY]

We've installed version 1.0.5 today running OS X 10.8.2 and had 3 kernel panics since, on two independent macs (Mid 2010 Mac Pro, MacBook Pro Retina). It seams to happen when exiting a terminal window via exit command or simply closing it.

[Nick]

Doing repetitive logins to remote units (450 of them, for updating their configuration) reliably panics the system).

The reason I suspect that it's sshpass is that I just now used it to do a interactive login, started ping and then exitted, don't know exactly how. The ping kept going, so the tty sshpass created was still alive.

I've since started to use our script in a Linux VM because the panics were very frequent.

[Jason Fesler]

Any update on this?

As of Mavericks 10.9.3 .. still happens. I've just gone through 5 gray screens until finding the common thread people are having (Ansible uses sshpass).

[Shachar Shemesh]

I'm sorry I missed this bug before.

This bug is a combination of two problems, and I'm afraid I can work on either one of them.

The first is the kernel panic itself. sshpass is an unprivileged user space only program. There is nothing a user space program can do that will legitimately trigger a kernel panic. As such, the bug is, first and foremost, in the OS X kernel. I suggest you open a bug with Apple (exact same description should be fine). I have no idea how responsive they are to bug reports, but I also have nothing I can do about it one way or the other.

One piece of advice I can give you, however, is that triggering a kernel crash from an unprivileged user space program is considered a denial of service attack, which means that you can mark the bug's severity as "security". Feel free to post a link to that bug here, so I can try and track it.

The other thing is that it's possible that sshpass is also doing something wrong. I will need more info in order to know what, however.

Missing details include: Step by step to reproduce? What command line is being used? What compilation flags were used to compile. Where the package was downloaded from? Whether any changes to the source were made? Anything else you can tell about the environment.

Jason uses Ansible - I suggest asking their support to look into it too (or, at the very least, send me a bug report with the full details of what's wrong). I'll note that I'm not sure I have access to a machine where I can even run these tests.

From your description it sounds like sshpass is working fine when not crashing the system. Under that condition, I'm inclined to think this is a kernel bug only (as opposed to both a kernel bug and a bug in sshpass). For that reason, pending more info, I'm closing this bug as "not a bug".

I'm sorry I couldn't be of more help.
Shachar

[Fedor Baart]

I can reproduce this issue using the following commands:

sshpass sleep 2
# CTRL-C
sshpass sleep 2
# panic, sometimes I have to do this a few times in a row.

Using Maverick, sshpass 1.0.5 from macports.

This results in the following panic:

Thu Jul 24 15:07:46 2014
panic(cpu 6 caller 0xffffff800a00cf7f): "negative open count (c, 16, 4)"@/SourceCache/xnu/xnu-2422.100.13/bsd/miscfs/specfs/spec_vnops.c:2110
Backtrace (CPU 6), Frame : Return Address
0xffffff81f8053b40 : 0xffffff8009e22fa9 
0xffffff81f8053bc0 : 0xffffff800a00cf7f 
0xffffff81f8053c00 : 0xffffff800a0123e6 
0xffffff81f8053c50 : 0xffffff8009ffdb0e 
0xffffff81f8053cc0 : 0xffffff8009fdbfc1 
0xffffff81f8053d10 : 0xffffff8009fdb710 
0xffffff81f8053d50 : 0xffffff8009fdc24d 
0xffffff81f8053d80 : 0xffffff8009ffe233 
0xffffff81f8053dd0 : 0xffffff800a1cedd6 
0xffffff81f8053e50 : 0xffffff8009e456e9 
0xffffff81f8053e80 : 0xffffff8009e487b9 
0xffffff81f8053eb0 : 0xffffff8009e4861e 
0xffffff81f8053ee0 : 0xffffff8009e20b93 
0xffffff81f8053f10 : 0xffffff8009edc593 
0xffffff81f8053f30 : 0xffffff8009ef3422

BSD process name corresponding to current thread: sleep

Mac OS version:
13D65

[Shachar Shemesh]

Thank you for the additional info. Assuming sshpass behaves as expected on those times that the kernel does not panic, I'm going to keep this filed as "not a bug" (more precisely, not a bug in sshpass).

If you can reproduce a case in which sshpass misbehaves while the kernel does not panic, please file a separate bug with a detailed description.

Shachar

[Fedor Baart]

Thanks, I'll try and find a corresponding bug at apple or submit it.

[Nick]

A similar kernel panic has been reported about extensively on the iTerm2 bug tracker:

https://code.google.com/p/iterm2/issues/detail?id=1765

The Darwin bug tracker lists it here:

http://openradar.appspot.com/14135782

According to the iTerm2 mailing list it has been fixed in Darwin. I haven't tried it on my up-to-date laptop, but I doubt whether Apple has copied that fix.