On Wed, 12 Jun 2002, William Craven wrote:
> When we narrowed the problem, we discovered that the Exim SMTP process
> that was attempting to authenticate our user was generating numerous
> brk() system calls. It seems, that the pam_converse() function, calling
> string_copy_malloc() is running away grabbing memory. See gdb output
> below.
> (gdb) bt
> #0 0xff1188ec in _brk_unlocked ()
> #1 0xff113468 in _sbrk_unlocked ()
> #2 0xff1133d8 in _sbrk ()
> #3 0xff0c1ec8 in _morecore ()
> #4 0xff0c1734 in _malloc_unlocked ()
> #5 0xff0c1494 in _smalloc ()
> #6 0xff0c1520 in malloc ()
> #7 0x4f7b8 in store_malloc_3 ()
> #8 0x50114 in string_copy_malloc ()
> #9 0x6aac0 in pam_converse ()
> #10 0xff2e4f80 in __pam_input_output ()
> #11 0xff2e2240 in pam_get_user ()
> #12 0xff054bbc in pam_sm_authenticate ()
> #13 0xff2e2620 in pam_authenticate ()
> #14 0x6abc0 in auth_call_pam ()
> #15 0x287ac in eval_condition ()
> #16 0x29bb8 in expand_string_internal ()
> #17 0x2b704 in expand_string ()
> #18 0x6c4f4 in auth_plaintext_server ()
> #19 0x4addc in smtp_setup_msg ()
> #20 0x158dc in handle_smtp_call ()
> #21 0x16da4 in daemon_go ()
> #22 0x261cc in main ()
That in itself looks unexceptional - though I don't know details of what
happens or should happen after Exim calls malloc(). This shows a call by
Exim to pam_authenticate() which eventually calls back to the Exim
function pam_converse(). It would be interesting to see the value of the
arguments passed to pam_converse(). The first is the number of bits of
data that PAM wants - this is usually 1. The number controls a loop
inside the function. There is (ultimately) a call to malloc() inside the
loop. So if a ridiculous number is being passed by PAM, chaos will
ensue.
Is there any way you can find this value? The source of pam_converse()
is in lookups/call_pam.c.
If it turns out to be a nonsensical value, I could put a check in there,
and return an error.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
