This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Difficulties with tzset() and setenv()



> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]