This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: [patch] Fix BZ 18985 out of bounds access in strftime


On 09/20/2015 12:38 AM, Paul Eggert wrote:
Paul Pluzhnikov wrote:
+  /* Do range checks first.  BZ #18985  */
+  if (tp->tm_sec < 0 || tp->tm_sec > 60
+      || tp->tm_min < 0 || tp->tm_min > 59
+      || tp->tm_hour < 0 || tp->tm_hour > 23
+      || tp->tm_mday < 0 || tp->tm_mday > 31
+      || tp->tm_mon < 0 || tp->tm_mon > 11
+      || tp->tm_wday < 0 || tp->tm_wday > 6
+      || tp->tm_yday < 0 || tp->tm_yday > 365
+      || tp->tm_isdst < 0 || tp->tm_isdst > 1)
+    {
+      __set_errno (EINVAL);
+      return 0;
+    }

That doesn't look right.  If the values are out of range, C11 and POSIX
say strftime is supposed to store an unspecified string, not return 0.

tzcode strftime stores "?" for out-of-range tm_mon and tm_wday, and
looks only at the sign of tm_isdst; this conforms to the standard.
FreeBSD strftime is similar.  glibc could do the same; that should be
both easy and compatible.

I tend to agree, although while I suspect it wasn't the intent,
an argument could be made that the patch is strictly conforming
on the basis that storing the unspecified characters would produce
a string that's longer than maxsize characters, in which case the
function is supposed to return 0.

Martin


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