Description of Problem:
Under some circumstances, xdm can be persuaded to catch a SIGSEGV.  I found
this while using some locally-developed modules (though it was pam_lastlog
that caught the SEGV) and I suspect that crafting a test case using the stock
modules will be tricky since it depends on the state of the malloc arena.

How Reproducible:
Easily if you have the right modules.  I can find the right set if it's really
necessary.

Additional Information:
The problem is in PAM_conv, in xc/programs/xdm/greeter/verify.c:

static int PAM_conv (int num_msg,
                     const struct pam_message **msg,
                     struct pam_response **resp,
                     void *appdata_ptr) {
        int replies = 0;
        struct pam_response *reply = NULL;

        reply = calloc(num_msg, sizeof(struct pam_response));
        if (!reply) return PAM_CONV_ERR;
#define COPY_STRING(s) (s) ? strdup(s) : NULL

        for (replies = 0; replies < num_msg; replies++) {
                switch (msg[replies]->msg_style) {
                case PAM_PROMPT_ECHO_OFF:
                        /* wants password */
                        reply[replies].resp_retcode = PAM_SUCCESS;
                        reply[replies].resp = COPY_STRING(PAM_password);
                        break;
                case PAM_TEXT_INFO:
                        /* ignore the informational mesage */
                        break;
                case PAM_PROMPT_ECHO_ON:
                        /* user name given to PAM already */
                        /* fall through */
                default:
                        /* unknown or PAM_ERROR_MSG */
                        free (reply);
                        return PAM_CONV_ERR;
                }
        }

#undef COPY_STRING
        *resp = reply;
        return PAM_SUCCESS;
}

There are two bugs here.  First, there are references to reply[replies], where
replies can be as large as num_msg-1, even though reply is only allocated
large enough to hold one pam_response.  This could cause heap corruption,
though I've not observed this.

The second problem is that in the case of a PAM_TEXT_INFO message, the resp
field of reply[replies] remains uninitialised, and thus when pam_lastlog
calls _pam_drop_reply() on the structure, it tries to free a random pointer,
with predictably nasty results.

A simple fix is to use calloc rather than malloc, and to pass it the number of
structures we need.  I'll attach a patch for this.