openssh-server dos regression in jaunty (oom_adj)

[Karsten Suehring]

Binary package hint: openssh-server

All child processes of openssh-server inherit the oom_adj value of -17 which makes the unkillable in low memory situation. Any user logged into the machine via ssh can cause a kernel-panic by creating a process that simply consumes memory.

I have reported this before for Hardy (Bug #293000). Upstream Debian fixes were shipped in Intrepid, Jaunty has the problem again.

Please fix openssh to degrade child processes to a higher oom_adj value.

[Karsten Suehring (suehring)]

I have done some more investigations on the issue. I found that the original debian patch still exists in sshd.

The problem is caused by the DHCP initialization of my network interface during startup. The DHCP request is processed in the background while the OpenSSH initialization script (and others) are already run. When the interface comes up,

/etc/network/if-up.d/openssh-server

is run. This scrips restarts sshd using the initialization script.

The problem is that the openssh-server script is run with oom_adj equal to -17. Thus sshd saves -17 as the target oom_adj value for all child processes and it appears as if the value would not be reset at all.

I would suggest adding the following line to /etc/network/if-up.d/openssh-server just before /etc/init.d/sshd restart is invoked:

echo 0 > /proc/self/oom_adj

Please consider adding this fix.

[Jamie Strandboge (jdstrand)]

Confirmed this on Jaunty when configured via dhcp. karmic does not seem to be affected.

[Robie Basak (racb)]

I think normal users should be limited by ulimit anyway. Then this wouldn't be a problem. See bug #182960.

[Daniel Hahler (blueyed)]

Assigning to dhcp, which appears to be causing it.
Please ignore/decline my nomination to fix this in Hardy: this bug is about the regression in Jaunty. For the bug in Hardy, see bug 293000.