From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: PATCH: utils.c: Fix use of uninitialized memory in metafy().
Date: Wed, 27 Nov 2013 17:19:37 -0800 [thread overview]
Message-ID: <131127171937.ZM23834@torch.brasslantern.com> (raw)
In-Reply-To: <20131127202602.3897f501@pws-pc.ntlworld.com>
On Nov 27, 8:26pm, Peter Stephenson wrote:
} Subject: Re: PATCH: utils.c: Fix use of uninitialized memory in metafy().
}
} On Wed, 27 Nov 2013 10:54:09 -0800
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > On Nov 27, 6:07pm, Peter Stephenson wrote:
} > }
} > } .... So if we've got only len valid bytes, not
} > } null-terminated (or null-terminated by accident because the next byte
} > } that isn't actually valid for the allocation happens to be null), we've
} > } got no way of knowing this given the current interface.
} >
} > Does it actually matter? The only reason for (*e != 0) as far as I can
} > tell is to be sure we've actually done (*e = '\0') at the very end of
} > the whole thing [comment: "... unchanged (a terminating null character
} > is appended to buf if necessary)"].
} >
} > Can't we just move the *e = '\0' outside the "if" body and skip the test
} > in the condition?
}
} Seems reasonable --- it requires the problem Simon was seeing to be in a
} case that's requesting reallocation, else that assignment is going to
} cause problems, but if it does cause problems we need to change the
} caller.
No, the problem Simon was seeing must in fact occur only in cases that
have no metacharacters and are NOT requesting reallocation, otherwise
the short-circuiting behavior of logical-or would never get as far as
testing (*e != '\0').
But (in the current code) if the test succeeds, then we enter the block
and execute *e = '\0', and if the test fails then *e == '\0' must be
true. The only case in which assigning '\0' could be a (new) problem is
one where the byte at buf[len] is already zero but is somehow in a part
of memory to which we aren't allowed to write.
Or where (len > 0 && *e && e != buf+len) but I don't see how that could
happen either. We could throw in a DPUTS if you are worried.
Simon's valgrind report wasn't a pointer out-of-bounds error, it was an
uninitialized memory error.
next prev parent reply other threads:[~2013-11-28 1:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-27 17:45 Simon Ruderich
2013-11-27 18:07 ` Peter Stephenson
2013-11-27 18:54 ` Bart Schaefer
2013-11-27 20:26 ` Peter Stephenson
2013-11-28 1:19 ` Bart Schaefer [this message]
2013-11-28 9:40 ` Peter Stephenson
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=131127171937.ZM23834@torch.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).