From: "Érico Nogueira" <ericonr@disroot.org>
To: <musl@lists.openwall.com>, <musl@lists.openwall.com>
Subject: Re: [musl] [PATCH] fix segfault in lutimes when tv argument is NULL
Date: Thu, 12 Nov 2020 16:43:04 -0300 [thread overview]
Message-ID: <C71JIQEF3ESL.4XZYDT3HINSL@mussels> (raw)
In-Reply-To: <20201112193207.GC2009@voyager>
On Thu Nov 12, 2020 at 5:32 PM -03, Markus Wichmann wrote:
> On Thu, Nov 12, 2020 at 03:43:27PM -0300, Érico Nogueira wrote:
> > From: Érico Rolim <ericonr@disroot.org>
> >
> > calling lutimes with tv=0 is valid if the applications wants to set the
> > timestamps to the current time. short-circuit the function to call
> > utimensat with times=0 directly if tv == 0.
> > ---
> >
> > Bug reported on IRC by nmeum
> >
> > src/legacy/lutimes.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/src/legacy/lutimes.c b/src/legacy/lutimes.c
> > index 2e5502d1..22176230 100644
> > --- a/src/legacy/lutimes.c
> > +++ b/src/legacy/lutimes.c
> > @@ -5,6 +5,7 @@
> >
> > int lutimes(const char *filename, const struct timeval tv[2])
> > {
> > + if (!tv) return utimensat(AT_FDCWD, filename, 0, AT_SYMLINK_NOFOLLOW);
> > struct timespec times[2];
> > times[0].tv_sec = tv[0].tv_sec;
> > times[0].tv_nsec = tv[0].tv_usec * 1000;
> > --
> > 2.29.2
> >
>
> Deja vu. We had a similar discussion in early March. The most recent
> e-mail in that thread stated that the patch "might be correct as-is."
> Though that patch did attempt to filter out invalid inputs as well. I
> had pointed out that the only spec available for lutimes does state that
> it should act like utimes(), and utimes() does allow for NULL inputs,
> but there was no reply. And no follow-up from the OP, either.
>
> Ciao,
> Markus
For reference, that thread starts at
https://www.openwall.com/lists/musl/2020/03/01/1
I based myself off of the futime() implementation, so both functions
have basically the same look / control flow now (except that futimes()
has the `struct timespec times[2]` declaration before the null check,
which I can fix in a v2, if necessary). Since it's a legacy function, I
didn't think it would be necessary to complicate matters further.
Re. checking the input values beyond a NULL check, futime() currently
doesn't do it, so for consistency's sake I think it would only make
sense to add that verification if it was added to futime() as well. That
said, I believe any verification should be left to utimensat(), which
seems to be called by most functions in the utimes family.
Cheers,
Érico
next prev parent reply other threads:[~2020-11-12 19:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-12 18:43 Érico Nogueira
2020-11-12 19:32 ` Markus Wichmann
2020-11-12 19:43 ` Érico Nogueira [this message]
2020-11-12 20:04 ` Rich Felker
2020-11-12 20:41 ` Érico Nogueira
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=C71JIQEF3ESL.4XZYDT3HINSL@mussels \
--to=ericonr@disroot.org \
--cc=musl@lists.openwall.com \
/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/musl/
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).