potential crash when deferencing null pointer returned from localtime or gmtime

[tsteven4]

If localtime encounters an error it will return a null pointer. Dereferencing a null pointer may result in a program crash. One way to have this happen is from QDateTime::toTime_t() which will return (unsigned int) -1 if the date is outside the range 1970-01-01T00:00:00 to 2106-02-07T06:28:14. Passing this to localtime can result in the return of a null pointer. This was demonstrated with the MinGW 32 bit compiler on windows with the stmsdf writer.

These usages do not check to see if localtime returns a null pointer before dereferencing it:
csv_util.cc: tm = *localtime(&time);
exif.cc: tm = *localtime(&time);
garmin_gpi.cc: tm = *localtime(&rdata->crdate);
garmin_txt.cc: tm = *localtime(&time);
ignrando.cc: tm = *localtime(&now);
stmsdf.cc: tm = *localtime(&ct);
stmsdf.cc: tm = *localtime(&start_time);
trackfilter.cc: tm = *localtime(&default_time);
trackfilter.cc: tm = *localtime(&t);
trackfilter.cc: t1 = *localtime(&tt1);
trackfilter.cc: t2 = *localtime(&tt2);
util.cc: check = *localtime(&result);

[GPSBabelDeveloper]

Memo to anyone tackling this, please do it by replacing localtime(), mkgmtime() and related code with code using DateTime or the subclassed variation of it in src/core/ instead of applying local anaesthesia to callers. I've been chipping away at this for years. Pretty much any place we see a struct tm is now a defect, IMO.

…

On Tue, Dec 5, 2017 at 6:03 PM, tsteven4 ***@***.***> wrote: If localtime encounters an error it will return a null pointer. Dereferencing a null pointer may result in a program crash. One way to have this happen is from QDateTime::toTime_t() which will return (unsigned int) -1 if the date is outside the range 1970-01-01T00:00:00 to 2106-02-07T06:28:14. Passing this to localtime can result in the return of a null pointer. This was demonstrated with the MinGW 32 bit compiler on windows with the stmsdf writer. These usages to not check to see if localtime returns a null pointer before dereferencing it: csv_util.cc: tm = *localtime(&time); exif.cc: tm = *localtime(&time); garmin_gpi.cc: tm = *localtime(&rdata->crdate); garmin_txt.cc: tm = *localtime(&time); ignrando.cc: tm = *localtime(&now); stmsdf.cc: tm = *localtime(&ct); stmsdf.cc: tm = *localtime(&start_time); trackfilter.cc: tm = *localtime(&default_time); trackfilter.cc: tm = *localtime(&t); trackfilter.cc: t1 = *localtime(&tt1); trackfilter.cc: t2 = *localtime(&tt2); util.cc: check = *localtime(&result); — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#141>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALdQD-PGls6rhGXo7PccKu-dz_yii-BTks5s9dnpgaJpZM4Q3KIf> .

[tsteven4]

as anticipated above, this can happen when dereferencing gmtime. This was demonstrated with the unicsv reader and the same compiler (Qt 5.5 for Destkop (MinGW 4.9.2 32 bit)). In both demonstrated cases a time before Jan 1, 1970 should do the trick.

These usages do not check the return of gmtime before dereferencing:
compegps.cc: struct tm tm = *gmtime(&tt);
csv_util.cc: tm = *gmtime(&time);
destinator.cc: tm = *gmtime(&ct);
exif.cc: tm = *gmtime(&tt);
garmin_gpi.cc: tm = *gmtime(&time);
garmin_txt.cc: tm = *gmtime(&time);
garmin_txt.cc: tm = *gmtime(&t);
ggv_log.cc: tm = *gmtime(&t);
jtr.cc: tm = *gmtime(&tt);
skyforce.cc: tm = *gmtime(&tt);
stmwpp.cc: tm = *gmtime(&tt);
trackfilter.cc: struct tm tm = *gmtime(&time);
unicsv.cc: struct tm tm = *gmtime(&res);
unicsv.cc: tm = *gmtime(&t);