[Bug 544] sshd w/privsep fails on Linux 2.0, mm_receive_fd: expected type 1 got 1074276337

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=544

           Summary: sshd w/privsep fails on Linux 2.0, mm_receive_fd:
                    expected type 1 got 1074276337
           Product: Portable OpenSSH
           Version: -current
          Platform: ix86
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: dtucker at zip.com.au


I'm attempting to reproduce some of the reported bugs on early Linuxes and I've 
found the following problem with privsep enabled (Debian slink, kernel 2.0.38, 
libc6 2.0.7).  It seems to be related to file descriptor passing.

$ ./sshd -ddd -p 2022
[snip]
debug3: mm_answer_pty entering
debug1: session_new: init
debug1: session_new: session 0
debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY
debug3: mm_request_receive_expect entering: type 26
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 26
mm_receive_fd: expected type 1 got 1074276337

It seems to be a bug in 2.0 kernels, cmsg_level and cmsg_type returned by 
recvmsg() make no sense.  I built a test program (which I will attach) from code 
from monitor_fdpass.c.

After the fd pass, a 2.0.38 kernel gives:
(gdb) print *cmsg
$1 = {cmsg_len = 16, cmsg_level = 134514016, cmsg_type = -1073742828,   
__cmsg_data = 0xbffffc08 "\005"}

A 2.4.18 kernel gives:
(gdb) print *cmsg
$1 = {cmsg_len = 16, cmsg_level = 1, cmsg_type = 1, __cmsg_data = 0xbffff5fc 
"\a"}

If you comment out the "if (cmsg->cmsg_type != SCM_RIGHTS)" test in 
mm_receive_fd(), privsep seems to work OK on 2.0 kernels.

I will reduce the test program to an autoconf test, add "#ifndef 
BROKEN_CMSG_TYPE" and attach the resulting patch.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.