From: Theodore Ts'o <tytso@mit.edu>
To: Peter Cordes <peter@cordes.ca>
Cc: util-linux@vger.kernel.org, Hornseth_Brenan@bah.com
Subject: Re: [PATCH] fsck: use xasprintf to avoid buffer overruns with an insane fs type
Date: Fri, 16 Feb 2018 12:10:40 -0500 [thread overview]
Message-ID: <20180216171040.GD12890@thunk.org> (raw)
In-Reply-To: <20180216155505.GL9479@cordes.ca>
On Fri, Feb 16, 2018 at 11:55:05AM -0400, Peter Cordes wrote:
> > - static char prog[256];
> > + static char *prog = NULL;
>
> You're allocating / freeing every time it's used, so it shouldn't be
> static anymore.
Good point. Karels has already accepted the patch, but if he hasn't
pushed it out, maybe he can ammend it.
> It might be easier to just use snprintf to truncate long strings,
> instead of introducing dynamic allocation which requires explicit
> freeing. OTOH xasprintf makes it re-entrant / thread-safe, at the
> cost of forcing the caller to care about memory management. (And at
> the cost of efficiency: prog is allocated / freed inside the loop.)
That's certainly an alternative, and in fact that's how I fixed it in
the old version of fsck still shipping in e2fsprogs (there are a few
places that still use it).
My main reason for using it there is that in e2fsprogs we don't assume
the use of xasprintf and family (it's a GNU extension, and e2fsprogs
tries to support legacy platforms such as MacOS and Windows :-).
However, given that fsck does use xasprintf already (and so there is
no portability advantag) and it's a lot easier to prove (or at least
satisfy to oneself) that an attacker who is trying to play tricks
can't do something unexpected when using xasprintf versus snprintf, I
went with asprintf in my patch to util-linux.
Cheers,
- Ted
next prev parent reply other threads:[~2018-02-16 17:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-15 20:05 [PATCH] fsck: use xasprintf to avoid buffer overruns with an insane fs type Theodore Ts'o
2018-02-16 9:54 ` Karel Zak
2018-02-16 15:55 ` Peter Cordes
2018-02-16 17:10 ` Theodore Ts'o [this message]
2018-02-16 18:08 ` Karel Zak
2018-02-17 0:29 ` Peter Cordes
2018-02-17 6:46 ` Theodore Ts'o
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=20180216171040.GD12890@thunk.org \
--to=tytso@mit.edu \
--cc=Hornseth_Brenan@bah.com \
--cc=peter@cordes.ca \
--cc=util-linux@vger.kernel.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.
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.