From: "R. Diez via newlib" <newlib@sourceware.org>
To: Craig Howland <howland@LGSInnovations.com>,
"newlib@sourceware.org" <newlib@sourceware.org>
Subject: Re: Difficulties with tzset() and setenv()
Date: Tue, 01 Aug 2017 06:57:00 -0000 [thread overview]
Message-ID: <1555153976.4703401.1501570616178@mail.yahoo.com> (raw)
In-Reply-To: <3994fcb0-a18b-4851-537b-1d29589c6320@LGSInnovations.com>
> You could try this as a workaround: set TZ to something
> "long," a value that you know will not be exceeded by
> any string you want to try. Instead of calling
> setenv() to change your value, simply overwrite the value
> at the pointer returned by getenv().
> (Certainly improper practice in general, but since
> you have seen the library internals, a valid workaround
> for the Newlib implementation that gets you going
> now without needing to wait for #2 to be addressed.)
It is an interesting work-around, thanks. I am still hoping for a "proper" solution though. 8-)
There is something else I wanted to mention in this mailing list.
Routine _tzset_unlocked_r() does not check whether sscanf() fails at this point:
if (*tzenv == '/')
sscanf (tzenv, "/%hu%n:%hu%n:%hu%n", &hh, &n, &mm, &n, &ss, &n);
Other calls to sscanf() in the same routine do check whether sscanf() has failed.
The %hu values captured are checked sometimes, but not in at least 2 sscanf() calls. I wonder if the end-user could trigger in this way an arithmetic overflow and then cause other problems later on. Date/time calculations do not usually involve buffers, so I hope that this lack of bounds checking does not create any security risks down the line.
Unfortunately, I do not have the time to address these issues myself at the moment.
Please copy me on any answers, as I am not subscribed to this mailing list.
Best regards,
rdiez
prev parent reply other threads:[~2017-08-01 6:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1022512790.3544807.1501484481626.ref@mail.yahoo.com>
2017-07-31 7:01 ` R. Diez via newlib
2017-07-31 15:56 ` Craig Howland
2017-08-01 6:57 ` R. Diez via newlib [this message]
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=1555153976.4703401.1501570616178@mail.yahoo.com \
--to=newlib@sourceware.org \
--cc=howland@LGSInnovations.com \
--cc=rdiezmail-newlib@yahoo.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).