From da277ce0db1a1649eb3efdd1b3cd738371c73ae0 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= Date: Tue, 10 Feb 2009 19:40:43 +0000 Subject: [PATCH] - fix *** %n in writable segment detected *** Changed files: cvs-printf-n.patch -> 1.1 --- cvs-printf-n.patch | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 cvs-printf-n.patch diff --git a/cvs-printf-n.patch b/cvs-printf-n.patch new file mode 100644 index 0000000..761fef0 --- /dev/null +++ b/cvs-printf-n.patch @@ -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 -- 2.44.0