Bug#57278: Crash on min/max + with date out of range.

MySQL officially supports DATE values starting from 1000-01-01. This is
enforced for int values, but not for string values, thus one
could easily insert '0001-01-01' value. Int values are checked by
number_to_datetime function and Item_cache_datetime::val_str uses it
to fill MYSQL_TIME struct out of cached int value. This leads to the
scenario where Item_cache_datetime caches a non-null datetime value and when
it tries to convert it from int to string number_to_datetime function
treats the value as out-of-range and returns an error and
Item_cache_datetime::val_str returns NULL for a non-null value. Due to this
inconsistency server crashes.

Now number_to_datetime allows DATE values below 1000-01-01 if the
TIME_FUZZY_DATE flag is set. Better NULL handling for Item_cache_datetime.
Added the Item_cache_datetime::store function to reset str_value_cached flag
when an item is stored.

1 files changed, 6 insertions, 1 deletions

diff --git a/sql-common/my_time.c b/sql-common/my_time.c
index ac6c2ace890..38384600fc1 100644
--- a/sql-common/my_time.c
+++ b/sql-common/my_time.c
@@ -1127,7 +1127,12 @@ longlong number_to_datetime(longlong nr, MYSQL_TIME *time_res,
     nr= (nr+19000000L)*1000000L;                 /* YYMMDD, year: 1970-1999 */
     goto ok;
   }
-  if (nr < 10000101L)
+  /*
+    Though officially we support DATE values from 1000-01-01 only, one can
+    easily insert a value like 1-1-1. So, for consistency reasons such dates
+    are allowed when TIME_FUZZY_DATE is set.
+  */
+  if (nr < 10000101L && !(flags & TIME_FUZZY_DATE))
     goto err;
   if (nr <= 99991231L)
   {