Steps to reproduce: Login to a 2.6.7 based kernel, g-d-s or h-d-s will work, login via ssh, use 'w' to check your current pty, run screen, run w, then logout of screen about 3-4 times then login again on a seperate terminal and check your new pty using 'w'. Expected behavior: Initial pty will be on pts/0, second ssh session, after screens are removed, will be on pts/1 instead of pts/5 or pts/6 Possible fixes can be found at: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7-rc2/2.6.7-rc2-mm2/broken-out/ as dynpty-fix.patch or pty-allocation-first-fit.patch I would suggest or fix this myself, but I'm not good enough to figure out how 1404_CAN-2004-0814.patch exactly modifies the same codebase (drivers/char) in a way that doesn't solve the existing pty problem. From Changelog-2.6.8: (line 4217) <hpa@zytor.com> [PATCH] Use first-fit for pty allocation (With Andrew Morton). The current dynamic pty allocation scheme has a few problems: - pty numbers grow to be very large, causing wtmp file bloat. - Seems to break libc5 and some old applications So change it to do first-fit. An IDR tree is used to provide a logarithmic-time search. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Please just upgrade to the 2.6.9 g-d-s kernel. It should be taken care of there.
Better just let the hardened guys know, I think they are still on 2.6.7 hardened: you may need to apply a patch to solve a memory leak, please read the body of this bug
Since h-d-s is still affected by this, I think it should remain open until such time as there is a reasonable fix for h-d-s (which is where I saw the problem in the first place)
Fixed in hardened-dev-sources-r18
Closing, please see comment #4...
