[OE-core] [PATCH 1/2] glibc: CVE-2015-1472: wscanf allocates too little memory
Khem Raj
raj.khem at gmail.com
Fri May 8 16:25:18 UTC 2015
this is ok
> On May 8, 2015, at 7:28 AM, Haris Okanovic <haris.okanovic at ni.com> wrote:
>
> Backport Paul Pluzhnikov's glibc patch for CVE-2015-1472:
>
> Under certain conditions wscanf can allocate too little memory for the
> to-be-scanned arguments and overflow the allocated buffer. The
> implementation now correctly computes the required buffer size when
> using malloc.
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=16618
>
> Signed-off-by: Haris Okanovic <haris.okanovic at ni.com>
> Signed-off-by: Ken Sharp <ken.sharp at ni.com>
> Reviewed-by: Rich Tollerton <rich.tollerton at ni.com>
> ---
> Natinst-CAR-ID: 518552
> Natinst-ReviewBoard-ID: 96712
> ---
> ...5-1472-wscanf-allocates-too-little-memory.patch | 127 +++++++++++++++++++++
> meta/recipes-core/glibc/glibc_2.20.bb | 1 +
> 2 files changed, 128 insertions(+)
> create mode 100644 meta/recipes-core/glibc/glibc/CVE-2015-1472-wscanf-allocates-too-little-memory.patch
>
> diff --git a/meta/recipes-core/glibc/glibc/CVE-2015-1472-wscanf-allocates-too-little-memory.patch b/meta/recipes-core/glibc/glibc/CVE-2015-1472-wscanf-allocates-too-little-memory.patch
> new file mode 100644
> index 0000000..4ffd609
> --- /dev/null
> +++ b/meta/recipes-core/glibc/glibc/CVE-2015-1472-wscanf-allocates-too-little-memory.patch
> @@ -0,0 +1,127 @@
> +From 5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06 Mon Sep 17 00:00:00 2001
> +From: Paul Pluzhnikov <ppluzhnikov at google.com>
> +Date: Fri, 6 Feb 2015 00:30:42 -0500
> +Subject: [PATCH] CVE-2015-1472: wscanf allocates too little memory
> +
> +BZ #16618
> +
> +Under certain conditions wscanf can allocate too little memory for the
> +to-be-scanned arguments and overflow the allocated buffer. The
> +implementation now correctly computes the required buffer size when
> +using malloc.
> +
> +A regression test was added to tst-sscanf.
> +
> +Upstream-Status: Backport
> +https://sourceware.org/bugzilla/show_bug.cgi?id=16618
> +---
> + stdio-common/tst-sscanf.c | 33 +++++++++++++++++++++++++++++++++
> + stdio-common/vfscanf.c | 12 ++++++------
> + 2 files changed, 39 insertions(+), 6 deletions(-)
> +
> +diff --git a/stdio-common/tst-sscanf.c b/stdio-common/tst-sscanf.c
> +index aece3f2f290088b2c08441cf85f2b915a61b9789..8a2eb9e39c4752a30941753d7f0325c2aa352fd1 100644
> +--- a/stdio-common/tst-sscanf.c
> ++++ b/stdio-common/tst-sscanf.c
> +@@ -226,12 +226,45 @@ main (void)
> + result = 1;
> + }
> + else if (ret == 2 && c != double_tests2[i].residual)
> + {
> + printf ("double_tests2[%d] stopped at '%c' != '%c'\n",
> + i, c, double_tests2[i].residual);
> + result = 1;
> + }
> + }
> +
> ++ /* BZ #16618
> ++ The test will segfault during SSCANF if the buffer overflow
> ++ is not fixed. The size of `s` is such that it forces the use
> ++ of malloc internally and this triggers the incorrect computation.
> ++ Thus the value for SIZE is arbitrariy high enough that malloc
> ++ is used. */
> ++ {
> ++#define SIZE 131072
> ++ CHAR *s = malloc ((SIZE + 1) * sizeof (*s));
> ++ if (s == NULL)
> ++ abort ();
> ++ for (size_t i = 0; i < SIZE; i++)
> ++ s[i] = L('0');
> ++ s[SIZE] = L('\0');
> ++ int i = 42;
> ++ /* Scan multi-digit zero into `i`. */
> ++ if (SSCANF (s, L("%d"), &i) != 1)
> ++ {
> ++ printf ("FAIL: bug16618: SSCANF did not read one input item.\n");
> ++ result = 1;
> ++ }
> ++ if (i != 0)
> ++ {
> ++ printf ("FAIL: bug16618: Value of `i` was not zero as expected.\n");
> ++ result = 1;
> ++ }
> ++ free (s);
> ++ if (result != 1)
> ++ printf ("PASS: bug16618: Did not crash.\n");
> ++#undef SIZE
> ++ }
> ++
> ++
> + return result;
> + }
> +diff --git a/stdio-common/vfscanf.c b/stdio-common/vfscanf.c
> +index cd129a81dee57e5e06ccb0e676e0de3fd52469ca..0e204e7b326d848716222f40b5b82b8256ed1b77 100644
> +--- a/stdio-common/vfscanf.c
> ++++ b/stdio-common/vfscanf.c
> +@@ -265,42 +265,42 @@ _IO_vfscanf_internal (_IO_FILE *s, const char *format, _IO_va_list argptr,
> + CHAR_T *wp = NULL; /* Workspace. */
> + size_t wpmax = 0; /* Maximal size of workspace. */
> + size_t wpsize; /* Currently used bytes in workspace. */
> + bool use_malloc = false;
> + #define ADDW(Ch) \
> + do \
> + { \
> + if (__glibc_unlikely (wpsize == wpmax)) \
> + { \
> + CHAR_T *old = wp; \
> +- size_t newsize = (UCHAR_MAX + 1 > 2 * wpmax \
> +- ? UCHAR_MAX + 1 : 2 * wpmax); \
> +- if (use_malloc || !__libc_use_alloca (newsize)) \
> ++ bool fits = __glibc_likely (wpmax <= SIZE_MAX / sizeof (CHAR_T) / 2); \
> ++ size_t wpneed = MAX (UCHAR_MAX + 1, 2 * wpmax); \
> ++ size_t newsize = fits ? wpneed * sizeof (CHAR_T) : SIZE_MAX; \
> ++ if (!__libc_use_alloca (newsize)) \
> + { \
> + wp = realloc (use_malloc ? wp : NULL, newsize); \
> + if (wp == NULL) \
> + { \
> + if (use_malloc) \
> + free (old); \
> + done = EOF; \
> + goto errout; \
> + } \
> + if (! use_malloc) \
> + MEMCPY (wp, old, wpsize); \
> +- wpmax = newsize; \
> ++ wpmax = wpneed; \
> + use_malloc = true; \
> + } \
> + else \
> + { \
> + size_t s = wpmax * sizeof (CHAR_T); \
> +- wp = (CHAR_T *) extend_alloca (wp, s, \
> +- newsize * sizeof (CHAR_T)); \
> ++ wp = (CHAR_T *) extend_alloca (wp, s, newsize); \
> + wpmax = s / sizeof (CHAR_T); \
> + if (old != NULL) \
> + MEMCPY (wp, old, wpsize); \
> + } \
> + } \
> + wp[wpsize++] = (Ch); \
> + } \
> + while (0)
> +
> + #ifdef __va_copy
> +--
> +2.2.2
> +
> diff --git a/meta/recipes-core/glibc/glibc_2.20.bb b/meta/recipes-core/glibc/glibc_2.20.bb
> index 3277f7a..e3427dd 100644
> --- a/meta/recipes-core/glibc/glibc_2.20.bb
> +++ b/meta/recipes-core/glibc/glibc_2.20.bb
> @@ -46,6 +46,7 @@ CVEPATCHES = "\
> file://CVE-2014-7817-wordexp-fails-to-honour-WRDE_NOCMD.patch \
> file://CVE-2012-3406-Stack-overflow-in-vfprintf-BZ-16617.patch \
> file://CVE-2014-9402_endless-loop-in-getaddr_r.patch \
> + file://CVE-2015-1472-wscanf-allocates-too-little-memory.patch \
> "
> LIC_FILES_CHKSUM = "file://LICENSES;md5=e9a558e243b36d3209f380deb394b213 \
> file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
> --
> 2.2.2
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150508/55fff689/attachment-0002.sig>
More information about the Openembedded-core
mailing list