Author: arekm Date: Tue Feb 10 19:40:49 2009 GMT Module: SOURCES Tag: HEAD ---- Log message: - fix *** %n in writable segment detected ***
---- Files affected: SOURCES: cvs-printf-n.patch (NONE -> 1.1) (NEW) ---- Diffs: ================================================================ Index: SOURCES/cvs-printf-n.patch diff -u /dev/null SOURCES/cvs-printf-n.patch:1.1 --- /dev/null Tue Feb 10 20:40:49 2009 +++ SOURCES/cvs-printf-n.patch Tue Feb 10 20:40:43 2009 @@ -0,0 +1,27 @@ +--- cvs-1.12.13/lib/vasnprintf.c 2005-05-23 19:44:33.000000000 +0200 ++++ cvs-1.12.13/lib/vasnprintf.c 2009-02-10 20:38:47.947197650 +0100 +@@ -558,9 +558,21 @@ + } + *p = dp->conversion; + #if USE_SNPRINTF +- p[1] = '%'; +- p[2] = 'n'; +- p[3] = '\0'; ++# if !(__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3)) ++ p[1] = '%'; ++ p[2] = 'n'; ++ p[3] = '\0'; ++# else ++ /* On glibc2 systems from glibc >= 2.3 - probably also older ++ ones - we know that snprintf's returns value conforms to ++ ISO C 99: the gl_SNPRINTF_DIRECTIVE_N test passes. ++ Therefore we can avoid using %n in this situation. ++ On glibc2 systems from 2004-10-18 or newer, the use of %n ++ in format strings in writable memory may crash the program ++ (if compiled with _FORTIFY_SOURCE=2), so we should avoid it ++ in this situation. */ ++ p[1] = '\0'; ++# endif + #else + p[1] = '\0'; + #endif ================================================================ _______________________________________________ pld-cvs-commit mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
