blob: 1dbaa51ec4c932c98268da0b4cdcae6aa5571632 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
Attemt to use CVS leads to glibc crash:
$ cvs up
*** %n in writable segment detected ***
Fixes: https://savannah.nongnu.org/bugs/?35432
Upstream gnulib commit:
From 913c09becd9df89dbd9b9f386e7f35c240d5efe8 Mon Sep 17 00:00:00 2001
From: Bruno Haible <bruno@clisp.org>
Date: Thu, 18 Oct 2007 23:50:42 +0000
Subject: Don't use %n on glibc >= 2.3 systems.
---
(limited to 'lib/vasnprintf.c')
diff --git a/lib/vasnprintf.c b/lib/vasnprintf.c
index f563823..5d818aa 100644
--- a/lib/vasnprintf.c
+++ b/lib/vasnprintf.c
@@ -3386,8 +3386,20 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
*fbp = dp->conversion;
#if USE_SNPRINTF
+# 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
--
cgit v0.9.0.2
|
GitWeb
