Bug 159958

Seems more like a consolehelper bug, reassing to component owner for some inputs.

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0804adf2 in converse_pipe (num_msg=0, msg=0x0, resp=0x0,
    appdata_ptr=0xbfc03224) at userhelper.c:408
408             if ((get_pam_string_item(data->pamh, PAM_USER, &user) !=
PAM_SUCCESS) ||
(gdb) bt
#0  0x0804adf2 in converse_pipe (num_msg=0, msg=0x0, resp=0x0,
    appdata_ptr=0xbfc03224) at userhelper.c:408
#1  0x0804b570 in pipe_conv_exec_start (conv=Variable "conv" is not available.
) at userhelper.c:943
#2  0x0804c494 in wrap (user=0x8c51b68 "ossman",
    program=0xbfc039d0 "ethereal", conv=0xbfc032a4, text_conv=0xbfc0329c,
    prompt=0x804ab3d <prompt_pipe>, argc=3, argv=0xbfc03354)
    at userhelper.c:1999
#3  0x0804d50f in main (argc=3, argv=0xbfc03354) at userhelper.c:2502

(gdb) print *((struct app_data*)appdata_ptr)
$4 = {pamh = 0x8c52c08, fallback_allowed = 1, fallback_chosen = 1,
  canceled = 0, input = 0x8c50358, output = 0x8c504c0, banner = 0x0,
  domain = 0xbfc039d0 "ethereal", sn_name = 0x0, sn_description = 0x0,
  sn_wmclass = 0x0, sn_binary_name = 0x0, sn_icon_name = 0x0, sn_id = 0x0,
  sn_workspace = -1}

It would seem that a bogus pointer is being written into &user:

(gdb) print user
$16 = 0x2000000 <Address 0x2000000 out of bounds>

The place of the sigsegv is also an optimised strlen(user) == NULL:

Dump of assembler code for function converse_pipe:
0x0804adcc <converse_pipe+0>:   push   %ebp
0x0804adcd <converse_pipe+1>:   mov    %esp,%ebp
0x0804adcf <converse_pipe+3>:   push   %edi
0x0804add0 <converse_pipe+4>:   push   %esi
0x0804add1 <converse_pipe+5>:   push   %ebx
0x0804add2 <converse_pipe+6>:   sub    $0x3c,%esp
0x0804add5 <converse_pipe+9>:   lea    0xfffffff0(%ebp),%ecx
0x0804add8 <converse_pipe+12>:  mov    $0x2,%edx
0x0804addd <converse_pipe+17>:  mov    0x14(%ebp),%ebx
0x0804ade0 <converse_pipe+20>:  mov    (%ebx),%eax
0x0804ade2 <converse_pipe+22>:  call   0x804a5a4 <get_pam_string_item>
0x0804ade7 <converse_pipe+27>:  test   %eax,%eax
0x0804ade9 <converse_pipe+29>:  jne    0x804adf7 <converse_pipe+43>
0x0804adeb <converse_pipe+31>:  mov    0xfffffff0(%ebp),%eax
0x0804adee <converse_pipe+34>:  test   %eax,%eax
0x0804adf0 <converse_pipe+36>:  je     0x804adf7 <converse_pipe+43>

0x0804adf2 <converse_pipe+38>:  cmpb   $0x0,(%eax)

0x0804adf5 <converse_pipe+41>:  jne    0x804adff <converse_pipe+51>
0x0804adf7 <converse_pipe+43>:  mov    $0x804f099,%eax
0x0804adfc <converse_pipe+48>:  mov    %eax,0xfffffff0(%ebp)
0x0804adff <converse_pipe+51>:  mov    %eax,0x10(%esp)
0x0804ae03 <converse_pipe+55>:  movl   $0x2a,0xc(%esp)

So this seems to be PAM bug.

Ok, reassigning to Tomas. Thanks for the analysis.

I'm not sure this is a PAM bug and I'm confused with the backtrace - this isn't
backtrace from a RHEL-3 userhelper but rather a FC-4 one.

This can be a completely different bug than the original report I think.

Pierre, which exact usermode version do you use? And on which exact
circumstances the crash happens?

Sorry, didn't see this was RHEL.

I'm running usermode-1.80-1. The bug appears when I click 'Run Unprivileged'.
Which application that is involved is irrelevant.

Hmmm back to userhelper - it calls pam functions after it had released the pam
handle by pam_end() call. Really nice work! :(

I've commented out the converse_pipe(0, NULL, NULL, data); at line 945 of
userhelper.c and it seems to work fine now. But I'm not sure this is the right
fix or if it isn't better to call the pam_end() in the fall back case after the
exec.

I didn't look at the RHEL-3 version but most probably there will be the same
problem.

*** Bug 166642 has been marked as a duplicate of this bug. ***

This is fixed in the current version of usermode (1.18-1 on FC devel). Go ahead
and close if the problem is gone on RHEL aswell.

This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.