From ripley at stats.ox.ac.uk  Tue Nov 20 14:45:09 2012
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Tue, 20 Nov 2012 13:45:09 +0000
Subject: [Rd] Buffer overflow in date package
In-Reply-To: <CAG=pywr8g5XzVhG6DqXPaO2+eSFre_P9iDU88rBAcFTACcLipQ@mail.gmail.com>
References: <CAG=pywr8g5XzVhG6DqXPaO2+eSFre_P9iDU88rBAcFTACcLipQ@mail.gmail.com>
Message-ID: <50AB8965.90907@stats.ox.ac.uk>

On 20/11/2012 06:49, Erik Doffagne wrote:
> Dear list-members,
>
> I have observed quite a strange problem with the date package.
>
> You will find below what I get on my machine (Ubuntu). I have been able to
> reproduce the error on Red Hat too. But it seems not to happen on Windows
> (and on some other Linux distros?).

You need to report this to the package maintainer (see the posting 
guide).  But running under valgrind shows why this is not reproducible:

==1487== Conditional jump or move depends on uninitialised value(s)
==1487==    at 0x4B9215: Rf_mkChar (envir.c:3380)
==1487==    by 0x49C471: do_dotCode (dotcode.c:2497)
==1487==    by 0x4C0ABD: Rf_eval (eval.c:494)
==1487==    by 0x4C4258: do_set (eval.c:1717)
==1487==    by 0x4C08DA: Rf_eval (eval.c:468)
==1487==    by 0x4C345F: do_begin (eval.c:1415)
==1487==    by 0x4C08DA: Rf_eval (eval.c:468)
==1487==    by 0x4C26D3: do_if (eval.c:1194)
==1487==    by 0x4C08DA: Rf_eval (eval.c:468)
==1487==    by 0x4C26D3: do_if (eval.c:1194)
==1487==    by 0x4C08DA: Rf_eval (eval.c:468)
==1487==    by 0x4C345F: do_begin (eval.c:1415)
==1487==  Uninitialised value was created by a heap allocation
==1487==    at 0x4A0762F: malloc (vg_replace_malloc.c:270)
==1487==    by 0x4F71CE: GetNewPage (memory.c:787)
==1487==    by 0x504851: Rf_allocVector (memory.c:2371)
==1487==    by 0x552FC3: ReadItem (serialize.c:1633)
==1487==    by 0x5536FD: ReadBC1 (serialize.c:1782)
==1487==    by 0x55361D: ReadBCConsts (serialize.c:1758)
==1487==    by 0x55374C: ReadBC1 (serialize.c:1784)
==1487==    by 0x5537D6: ReadBC (serialize.c:1794)
==1487==    by 0x5531B3: ReadItem (serialize.c:1660)
==1487==    by 0x552AD2: ReadItem (serialize.c:1571)
==1487==    by 0x5539A0: R_Unserialize (serialize.c:1837)
==1487==    by 0x5552E0: R_unserialize (serialize.c:2456)
==1487==
[1] <NA>


>
>> require(date)
> Loading required package: date
>> sessionInfo()
> R version 2.15.2 (2012-10-26)
> Platform: x86_64-pc-linux-gnu (64-bit)
>
> locale:
>   [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
>   [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>   [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
>   [7] LC_PAPER=C                 LC_NAME=C
>   [9] LC_ADDRESS=C               LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base
>
> other attached packages:
> [1] date_1.2-32
>> as.date("1921994")
> *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated
> ======= Backtrace: =========
> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f46659ca007]
> /lib/x86_64-linux-gnu/libc.so.6(+0x107f00)[0x7f46659c8f00]
> /lib/x86_64-linux-gnu/libc.so.6(+0x107369)[0x7f46659c8369]
>
> I have tried to isolate the problem by calling the C code from the date
> package without R.
>
> #include "char_date.c"
>
>   int main()
>   { int nv = 1;
>     int order[] = {2,3,1};
>     char cdatev[] = "1921994";
>     int month[] = {0};
>     int day[] = {0};
>     int year[] = {0};
>     int *n = &nv;
>     int i;
>     int size = strlen(cdatev);
>     char *cdate[size];
>     for (i=0;i<size;i++) cdate[i] = &cdatev[i];

This fails to terminate cdate, and the C code does do strlen() on it.

>     char_date(n, order, cdate, month, day, year);
>     printf("%d-%d-%d\n",day[0],month[0],year[0]);
>     return(0);
>   }
>
> Depending on the compilation flags, I get different behavior:
>
> $ gcc rundate.c -o rundate.o
> $ ./rundate.o
> 92-1-1994
>
> $ gcc rundate.c -O3 -o rundate.o
> $ ./rundate.o
> *** buffer overflow detected ***: ./rundate.o terminated
> ======= Backtrace: =========
> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f17fdfb9007]
> /lib/x86_64-linux-gnu/libc.so.6(+0x107f00)[0x7f17fdfb7f00]
> /lib/x86_64-linux-gnu/libc.so.6(+0x107369)[0x7f17fdfb7369]
>
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
> 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
> --program-suffix=-4.6 --enable-shared --enable-linker-build-id
> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --enable-gnu-unique-object --enable-plugin --enable-objc-gc
> --disable-werror --with-arch-32=i686 --with-tune=generic
> --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>
> Does anyone is able to reproduce this error ? Any thoughts what could be
> wrong ?
>
> Thanks in advance.
>
> Erik
>
> 	[[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595



[Rd] Buffer overflow in date package
Prof Brian Ripley