public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
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

      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).