All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH] imap-send: handle NULL return of next_arg()
Date: Thu, 02 Nov 2017 11:18:42 +0900	[thread overview]
Message-ID: <xmqqefphs9rx.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <2d466b78-77fc-fa2c-c5e1-7b8737a00958@web.de> ("René Scharfe"'s message of "Wed, 1 Nov 2017 18:03:20 +0100")

René Scharfe <l.s.r@web.de> writes:

> @@ -807,6 +816,8 @@ static int get_cmd_result(struct imap_store *ctx, struct imap_cmd *tcmd)
>  			if (cmdp->cb.cont || cmdp->cb.data)
>  				imap->literal_pending = 0;
>  			arg = next_arg(&cmd);
> +			if (!arg)
> +				arg = "";

This is being cute and needs reading of the post-context a bit.

         arg = next_arg(&cmd);
+        if (!arg)
+                arg = "";
         if (!strcmp("OK", arg))
                 resp = DRV_OK;
         else {
                 if (!strcmp("NO", arg))
                         resp = RESP_NO;
                 else /*if (!strcmp("BAD", arg))*/
                         resp = RESP_BAD;
                 fprintf(stderr, "IMAP command '%s' returned response (%s) - %s\n",
                         !starts_with(cmdp->cmd, "LOGIN") ?
                                         cmdp->cmd : "LOGIN <user> <pass>",
                                         arg, cmd ? cmd : "");
         }
         if ((resp2 = parse_response_code(ctx, &cmdp->cb, cmd)) > resp)
                 resp = resp2;


Because the existing code does not explicitly check for "BAD", we
get RESP_BAD, which is what we want in the end, and the error
message we give has "returned response (%s)" which is filled with
this empty string.

I notice that when this change matters, i.e. we hit a premature end,
next_arg() that yielded NULL would have cleared cmd.  That is OK for
the fprintf() we see above, but wouldn't it hit parse_response_code()
that is shared between good and bad cases?  The function starts like
so:

    static int parse_response_code(struct imap_store *ctx, struct imap_cmd_cb *cb,
                                   char *s)
    {
            struct imap *imap = ctx->imap;
            char *arg, *p;

            if (*s != '[')
                    return RESP_OK;		/* no response code */

so we will get an immediate NULL dereference, it appears.

The fixes in other hunks looked OK (and not cute).


  reply	other threads:[~2017-11-02  2:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01 17:03 [PATCH] imap-send: handle NULL return of next_arg() René Scharfe
2017-11-02  2:18 ` Junio C Hamano [this message]
2017-11-02 17:27   ` René Scharfe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqefphs9rx.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.