From 368ac9f03ef9c1f0c9d02985c13708ac52cfbfaf Mon Sep 17 00:00:00 2001 From: Evgeny Potemkin Date: Thu, 4 Nov 2010 16:18:27 +0300 Subject: 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. mysql-test/r/type_date.result: Added a test case for the bug#57278. mysql-test/t/type_date.test: Added a test case for the bug#57278. sql-common/my_time.c: Bug#57278: Crash on min/max + with date out of range. Now number_to_datetime allows DATE values below 1000-01-01 if the TIME_FUZZY_DATE flag is set. sql/item.cc: Bug#57278: Crash on min/max + with date out of range. Item_cache_datetime::val_str now better handles null_value. --- sql-common/my_time.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'sql-common/my_time.c') 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) { -- cgit v1.2.1 From a70c34bf0f34703fd330f8cb828e48b303c5296a Mon Sep 17 00:00:00 2001 From: Georgi Kodinov Date: Wed, 2 Feb 2011 18:51:35 +0200 Subject: Fixes for Bug #55755 and Bug #52315 part 2 Bug #55755 : Date STD variable signness breaks server on FreeBSD and OpenBSD * Added a check to configure on the size of time_t * Created a macro to check for a valid time_t that is safe to use with datetime functions and store in TIMESTAMP columns. * Used the macro consistently instead of the ad-hoc checks introduced by 52315 * Fixed compliation warnings on platforms where the size of time_t is smaller than the size of a long (e.g. OpenBSD 4.8 64 amd64). Bug #52315: utc_date() crashes when system time > year 2037 * Added a correct check for the timestamp range instead of just variable size check to SET TIMESTAMP. * Added overflow checking before converting to time_t. * Using a correct localized error message in this case instead of the generic error. * Added a test suite. * fixed the checks so that they check for unsigned time_t as well. Used the checks consistently across the source code. * fixed the original test case to expect the new error code. --- sql-common/my_time.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'sql-common/my_time.c') diff --git a/sql-common/my_time.c b/sql-common/my_time.c index ed1279f7afb..07cb8b25c46 100644 --- a/sql-common/my_time.c +++ b/sql-common/my_time.c @@ -985,7 +985,7 @@ my_system_gmt_sec(const MYSQL_TIME *t_src, long *my_timezone, with unsigned time_t tmp+= shift*86400L might result in a number, larger then TIMESTAMP_MAX_VALUE, so another check will work. */ - if ((tmp < TIMESTAMP_MIN_VALUE) || (tmp > TIMESTAMP_MAX_VALUE)) + if (!IS_TIME_T_VALID_FOR_TIMESTAMP(tmp)) tmp= 0; return (my_time_t) tmp; -- cgit v1.2.1 From a60c39a2ffc7ec0c0b4ae8bbadf733773ec7557f Mon Sep 17 00:00:00 2001 From: Sergey Glukhov Date: Wed, 27 Apr 2011 11:35:57 +0400 Subject: Bug#11889186 60503: CRASH IN MAKE_DATE_TIME WITH DATE_FORMAT / STR_TO_DATE COMBINATION calc_daynr() function returns negative result if malformed date with zero year and month is used. Attempt to calculate week day on negative value leads to crash. The fix is return NULL for 'W', 'a', 'w' specifiers if zero year and month is used. Additional fix for calc_daynr(): --added assertion that result can not be negative --return 0 if zero year and month is used mysql-test/r/func_time.result: test case mysql-test/t/func_time.test: test case sql-common/my_time.c: --added assertion that result can not be negative --return 0 if zero year and month is used sql/item_timefunc.cc: eturn NULL for 'W', 'a', 'w' specifiers if zero year and month is used. --- sql-common/my_time.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'sql-common/my_time.c') diff --git a/sql-common/my_time.c b/sql-common/my_time.c index ca11c54a999..80a7e0daa2c 100644 --- a/sql-common/my_time.c +++ b/sql-common/my_time.c @@ -772,7 +772,7 @@ long calc_daynr(uint year,uint month,uint day) int y= year; /* may be < 0 temporarily */ DBUG_ENTER("calc_daynr"); - if (y == 0 && month == 0 && day == 0) + if (y == 0 && month == 0) DBUG_RETURN(0); /* Skip errors */ /* Cast to int to be able to handle month == 0 */ delsum= (long) (365 * y + 31 *((int) month - 1) + (int) day); @@ -783,6 +783,7 @@ long calc_daynr(uint year,uint month,uint day) temp=(int) ((y/100+1)*3)/4; DBUG_PRINT("exit",("year: %d month: %d day: %d -> daynr: %ld", y+(month <= 2),month,day,delsum+y/4-temp)); + DBUG_ASSERT(delsum+(int) y/4-temp > 0); DBUG_RETURN(delsum+(int) y/4-temp); } /* calc_daynr */ -- cgit v1.2.1