linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] zlib double-free bug
@ 2002-03-18 10:57 Paul Mackerras
  2002-03-18 14:49 ` J.A. Magallon
  2002-03-19  5:01 ` Paul Mackerras
  0 siblings, 2 replies; 25+ messages in thread
From: Paul Mackerras @ 2002-03-18 10:57 UTC (permalink / raw)
  To: marcelo, linux-kernel

Recently CERT published an advisory, warning about a bug in zlib where
a chunk of memory could get freed twice, depending on the data being
decompressed, which could potentially give a way to attack a system
using zlib.  The reference is

	http://www.cert.org/advisories/CA-2002-07.html

All 3 of the versions of zlib in the current 2.4 kernel have this bug.
The version in 2.5 doesn't because it handles memory allocation in a
different way.

The patch below fixes this bug in each of the three copies of zlib.c,
in the same way that it is fixed in the zlib-1.1.4 release (basically
by making sure that s->sub.trees.blens is always freed whenever, and
only when, s->mode is changed from BTREE or DTREE to some other value).

In the longer term I recommend that the 2.5.x changes to use a single
copy of zlib in lib/zlib_{deflate,inflate} should be back-ported to
2.4.  For now, this patch should be applied to 2.4.x since the bug is
a potential security hole if you are using PPP with Deflate
compression.

The patch also raises the minimum value of `windowBits' for
compression from 8 to 9, since using windowBits==8 causes memory
corruption (this was discovered by James Carlson, see
http://playground.sun.com/~carlsonj/ for details).  Current versions
of pppd avoid using windowBits==8 for this reason, but it is better to
have zlib protect itself as well.

Paul.

diff -urN linux-2.4.19-pre3/arch/ppc/boot/lib/zlib.c pmac/arch/ppc/boot/lib/zlib.c
--- linux-2.4.19-pre3/arch/ppc/boot/lib/zlib.c	Mon Mar 18 13:34:47 2002
+++ pmac/arch/ppc/boot/lib/zlib.c	Mon Mar 18 21:15:55 2002
@@ -928,7 +928,10 @@
       {
         r = t;
         if (r == Z_DATA_ERROR)
+	{
+          ZFREE(z, s->sub.trees.blens, s->sub.trees.nblens * sizeof(uInt));
           s->mode = BADB;
+	}
         LEAVE
       }
       s->sub.trees.index = 0;
@@ -964,6 +967,7 @@
           if (i + j > 258 + (t & 0x1f) + ((t >> 5) & 0x1f) ||
               (c == 16 && i < 1))
           {
+            ZFREE(z, s->sub.trees.blens, s->sub.trees.nblens * sizeof(uInt));
             s->mode = BADB;
             z->msg = "invalid bit length repeat";
             r = Z_DATA_ERROR;
@@ -991,7 +995,10 @@
         if (t != Z_OK)
         {
           if (t == (uInt)Z_DATA_ERROR)
+	  {
+            ZFREE(z, s->sub.trees.blens, s->sub.trees.nblens * sizeof(uInt));
             s->mode = BADB;
+	  }
           r = t;
           LEAVE
         }
@@ -1003,11 +1010,11 @@
           r = Z_MEM_ERROR;
           LEAVE
         }
-        ZFREE(z, s->sub.trees.blens, s->sub.trees.nblens * sizeof(uInt));
         s->sub.decode.codes = c;
         s->sub.decode.tl = tl;
         s->sub.decode.td = td;
       }
+      ZFREE(z, s->sub.trees.blens, s->sub.trees.nblens * sizeof(uInt));
       s->mode = CODES;
     case CODES:
       UPDATE
diff -urN linux-2.4.19-pre3/drivers/net/zlib.c pmac/drivers/net/zlib.c
--- linux-2.4.19-pre3/drivers/net/zlib.c	Sat Apr 28 23:02:45 2001
+++ pmac/drivers/net/zlib.c	Mon Mar 18 12:12:17 2002
@@ -14,7 +14,7 @@
  */
 
 /* 
- *  ==FILEVERSION 971210==
+ *  ==FILEVERSION 20020318==
  *
  * This marker is used by the Linux installation script to determine
  * whether an up-to-date version of this file is already installed.
@@ -772,7 +772,7 @@
         windowBits = -windowBits;
     }
     if (memLevel < 1 || memLevel > MAX_MEM_LEVEL || method != Z_DEFLATED ||
-        windowBits < 8 || windowBits > 15 || level < 0 || level > 9 ||
+        windowBits < 9 || windowBits > 15 || level < 0 || level > 9 ||
 	strategy < 0 || strategy > Z_HUFFMAN_ONLY) {
         return Z_STREAM_ERROR;
     }
@@ -3860,10 +3860,12 @@
                              &s->sub.trees.tb, z);
       if (t != Z_OK)
       {
-        ZFREE(z, s->sub.trees.blens);
         r = t;
         if (r == Z_DATA_ERROR)
+	{
+	  ZFREE(z, s->sub.trees.blens);
           s->mode = BADB;
+	}
         LEAVE
       }
       s->sub.trees.index = 0;
@@ -3928,11 +3930,13 @@
 #endif
         t = inflate_trees_dynamic(257 + (t & 0x1f), 1 + ((t >> 5) & 0x1f),
                                   s->sub.trees.blens, &bl, &bd, &tl, &td, z);
-        ZFREE(z, s->sub.trees.blens);
         if (t != Z_OK)
         {
           if (t == (uInt)Z_DATA_ERROR)
+	  {
+	    ZFREE(z, s->sub.trees.blens);
             s->mode = BADB;
+	  }
           r = t;
           LEAVE
         }
@@ -3949,6 +3953,7 @@
         s->sub.decode.tl = tl;
         s->sub.decode.td = td;
       }
+      ZFREE(z, s->sub.trees.blens);
       s->mode = CODES;
     case CODES:
       UPDATE
diff -urN linux-2.4.19-pre3/fs/jffs2/zlib.c pmac/fs/jffs2/zlib.c
--- linux-2.4.19-pre3/fs/jffs2/zlib.c	Mon Sep 24 09:31:33 2001
+++ pmac/fs/jffs2/zlib.c	Mon Mar 18 21:16:32 2002
@@ -14,7 +14,7 @@
  */
 
 /* 
- *  ==FILEVERSION 971210==
+ *  ==FILEVERSION 20020318==
  *
  * This marker is used by the Linux installation script to determine
  * whether an up-to-date version of this file is already installed.
@@ -772,7 +772,7 @@
         windowBits = -windowBits;
     }
     if (memLevel < 1 || memLevel > MAX_MEM_LEVEL || method != Z_DEFLATED ||
-        windowBits < 8 || windowBits > 15 || level < 0 || level > 9 ||
+        windowBits < 9 || windowBits > 15 || level < 0 || level > 9 ||
 	strategy < 0 || strategy > Z_HUFFMAN_ONLY) {
         return Z_STREAM_ERROR;
     }
@@ -3860,10 +3860,12 @@
                              &s->sub.trees.tb, z);
       if (t != Z_OK)
       {
-        ZFREE(z, s->sub.trees.blens);
         r = t;
         if (r == Z_DATA_ERROR)
+	{
+	  ZFREE(z, s->sub.trees.blens);
           s->mode = BADB;
+	}
         LEAVE
       }
       s->sub.trees.index = 0;
@@ -3928,11 +3930,13 @@
 #endif
         t = inflate_trees_dynamic(257 + (t & 0x1f), 1 + ((t >> 5) & 0x1f),
                                   s->sub.trees.blens, &bl, &bd, &tl, &td, z);
-        ZFREE(z, s->sub.trees.blens);
         if (t != Z_OK)
         {
           if (t == (uInt)Z_DATA_ERROR)
+	  {
+	    ZFREE(z, s->sub.trees.blens);
             s->mode = BADB;
+	  }
           r = t;
           LEAVE
         }
@@ -3949,6 +3953,7 @@
         s->sub.decode.tl = tl;
         s->sub.decode.td = td;
       }
+      ZFREE(z, s->sub.trees.blens);
       s->mode = CODES;
     case CODES:
       UPDATE

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-18 10:57 [PATCH] zlib double-free bug Paul Mackerras
@ 2002-03-18 14:49 ` J.A. Magallon
  2002-03-18 15:15   ` Tom Rini
  2002-03-18 16:36   ` David Woodhouse
  2002-03-19  5:01 ` Paul Mackerras
  1 sibling, 2 replies; 25+ messages in thread
From: J.A. Magallon @ 2002-03-18 14:49 UTC (permalink / raw)
  To: paulus; +Cc: marcelo, linux-kernel


On 2002.03.18 Paul Mackerras wrote:
>Recently CERT published an advisory, warning about a bug in zlib where
>a chunk of memory could get freed twice, depending on the data being
>decompressed, which could potentially give a way to attack a system
>using zlib.  The reference is
>
>	http://www.cert.org/advisories/CA-2002-07.html
>
>All 3 of the versions of zlib in the current 2.4 kernel have this bug.
>The version in 2.5 doesn't because it handles memory allocation in a
>different way.
>
>The patch below fixes this bug in each of the three copies of zlib.c,
>in the same way that it is fixed in the zlib-1.1.4 release (basically
>by making sure that s->sub.trees.blens is always freed whenever, and
>only when, s->mode is changed from BTREE or DTREE to some other value).
>
>In the longer term I recommend that the 2.5.x changes to use a single
>copy of zlib in lib/zlib_{deflate,inflate} should be back-ported to
>2.4.  For now, this patch should be applied to 2.4.x since the bug is
>a potential security hole if you are using PPP with Deflate
>compression.
>

Someone posted it was here:

ftp://ftp.kernel.org/pub/linux/kernel/people/dwmw2/shared-zlib/

The only rest it leaves in 19-pre3 are:

./arch/ppc/boot/lib/zlib.c
./arch/ppc/boot/include/zlib.h

Patch already does:

--- linux-2.4.19-pre2-ac2/arch/ppc/config.in    Sun Mar  3 18:54:31 2002
+++ linux-2.4.19-pre2-ac2-zlib/arch/ppc/config.in   Tue Mar  5 08:57:31 2002
@@ -396,6 +396,8 @@
    source net/bluetooth/Config.in
 fi
 
+source lib/Config.in
+  
 mainmenu_option next_comment
 comment 'Kernel hacking'
 

So wouldn't it be better to kill ppc/.../zlib and make it use also the
shared copy ?

BTW, it is the ONLY file in arch/ppc/boot/lib, so whole dir could be killed
(at least in standard tree, do not know in ppc branch...)


-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.2 (Bluebird) for i586
Linux werewolf 2.4.19-pre3-jam3 #1 SMP Fri Mar 15 01:16:08 CET 2002 i686

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-18 14:49 ` J.A. Magallon
@ 2002-03-18 15:15   ` Tom Rini
  2002-03-18 16:36   ` David Woodhouse
  1 sibling, 0 replies; 25+ messages in thread
From: Tom Rini @ 2002-03-18 15:15 UTC (permalink / raw)
  To: J.A. Magallon; +Cc: paulus, marcelo, linux-kernel

On Mon, Mar 18, 2002 at 03:49:46PM +0100, J.A. Magallon wrote:
 
> The only rest it leaves in 19-pre3 are:
> 
> ./arch/ppc/boot/lib/zlib.c
> ./arch/ppc/boot/include/zlib.h
> 
> Patch already does:
> 
> --- linux-2.4.19-pre2-ac2/arch/ppc/config.in    Sun Mar  3 18:54:31 2002
> +++ linux-2.4.19-pre2-ac2-zlib/arch/ppc/config.in   Tue Mar  5 08:57:31 2002
> @@ -396,6 +396,8 @@
>     source net/bluetooth/Config.in
>  fi
>  
> +source lib/Config.in
> +  
>  mainmenu_option next_comment
>  comment 'Kernel hacking'
>  
> 
> So wouldn't it be better to kill ppc/.../zlib and make it use also the
> shared copy ?

Not really.  The arch/ppc/boot version (and arch/mips/boot'ish too, when
it gets merged) are slightly different from the in-kernel ones by ~1
line, so that they allow things to be decompressed to 0x0.  My plan for
2.5 is to get the PPC version using the lib/zlib_deflate stuff (by dummy
files doing #include too), maybe.  But either way it's a non-issue (if
you can't trust the 'zImage' binary, you've got bigger problems than
someone trying to expliot a bug before Linux is running).

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-18 14:49 ` J.A. Magallon
  2002-03-18 15:15   ` Tom Rini
@ 2002-03-18 16:36   ` David Woodhouse
  2002-03-18 22:09     ` Paul Mackerras
  1 sibling, 1 reply; 25+ messages in thread
From: David Woodhouse @ 2002-03-18 16:36 UTC (permalink / raw)
  To: J.A. Magallon; +Cc: paulus, marcelo, linux-kernel


jamagallon@able.es said:
>  Someone posted it was here:
> ftp://ftp.kernel.org/pub/linux/kernel/people/dwmw2/shared-zlib/ 

Also bk://linux-mtd.bkbits.net/zlib-2.4 and in 2.4.19-ac.

After it's been in -ac for a while without mishap I'll ask Marcelo to
consider it - possibly for 2.4.20-pre1.

--
dwmw2



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-18 16:36   ` David Woodhouse
@ 2002-03-18 22:09     ` Paul Mackerras
  2002-03-19 10:45       ` David Woodhouse
  0 siblings, 1 reply; 25+ messages in thread
From: Paul Mackerras @ 2002-03-18 22:09 UTC (permalink / raw)
  To: David Woodhouse; +Cc: J.A. Magallon, marcelo, linux-kernel

David Woodhouse writes:

> After it's been in -ac for a while without mishap I'll ask Marcelo to
> consider it - possibly for 2.4.20-pre1.

Yep, that sounds good to me.  For now, I think my patch should go in
for 2.4.19.

Anyone who is using PPP with Deflate compression on an older 2.4.x
kernel (or for that matter a 2.2.x kernel) should apply my patch
also, or at least the part of it that affects drivers/net/zlib.c.

Paul.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-18 10:57 [PATCH] zlib double-free bug Paul Mackerras
  2002-03-18 14:49 ` J.A. Magallon
@ 2002-03-19  5:01 ` Paul Mackerras
  1 sibling, 0 replies; 25+ messages in thread
From: Paul Mackerras @ 2002-03-19  5:01 UTC (permalink / raw)
  To: marcelo, linux-kernel

Someone pointed me at a previously-posted patch for the zlib
vulnerability.  While I was looking at that patch I realized that both
that patch and mine were buggy in different ways.  My patch was
freeing s->sub.trees.blens after that word had been overwritten by an
assignment to s->sub.decode.codes, whereas with the previously-posted
patch, it is still possible to get a double-free (if inflate_codes_new
returns NULL, it will leave s->mode == DTREE but s->sub.trees.blens
has already been freed).

Here is a new patch which should fix both those problems.

Paul.

diff -urN linux-2.4.19-pre3/arch/ppc/boot/lib/zlib.c pmac/arch/ppc/boot/lib/zlib.c
--- linux-2.4.19-pre3/arch/ppc/boot/lib/zlib.c	Mon Mar 18 13:34:47 2002
+++ pmac/arch/ppc/boot/lib/zlib.c	Tue Mar 19 15:46:09 2002
@@ -1,5 +1,5 @@
 /*
- * BK Id: SCCS/s.zlib.c 1.10 01/11/02 10:46:07 trini
+ * BK Id: SCCS/s.zlib.c 1.9 12/05/01 16:19:42 mporter
  */
 /*
  * This file is derived from various .h and .c files from the zlib-0.95
@@ -928,7 +928,10 @@
       {
         r = t;
         if (r == Z_DATA_ERROR)
+	{
+          ZFREE(z, s->sub.trees.blens, s->sub.trees.nblens * sizeof(uInt));
           s->mode = BADB;
+	}
         LEAVE
       }
       s->sub.trees.index = 0;
@@ -964,6 +967,7 @@
           if (i + j > 258 + (t & 0x1f) + ((t >> 5) & 0x1f) ||
               (c == 16 && i < 1))
           {
+            ZFREE(z, s->sub.trees.blens, s->sub.trees.nblens * sizeof(uInt));
             s->mode = BADB;
             z->msg = "invalid bit length repeat";
             r = Z_DATA_ERROR;
@@ -991,7 +995,10 @@
         if (t != Z_OK)
         {
           if (t == (uInt)Z_DATA_ERROR)
+	  {
+            ZFREE(z, s->sub.trees.blens, s->sub.trees.nblens * sizeof(uInt));
             s->mode = BADB;
+	  }
           r = t;
           LEAVE
         }
diff -urN linux-2.4.19-pre3/drivers/net/zlib.c pmac/drivers/net/zlib.c
--- linux-2.4.19-pre3/drivers/net/zlib.c	Sat Apr 28 23:02:45 2001
+++ pmac/drivers/net/zlib.c	Tue Mar 19 15:45:40 2002
@@ -14,7 +14,7 @@
  */
 
 /* 
- *  ==FILEVERSION 971210==
+ *  ==FILEVERSION 20020318==
  *
  * This marker is used by the Linux installation script to determine
  * whether an up-to-date version of this file is already installed.
@@ -772,7 +772,7 @@
         windowBits = -windowBits;
     }
     if (memLevel < 1 || memLevel > MAX_MEM_LEVEL || method != Z_DEFLATED ||
-        windowBits < 8 || windowBits > 15 || level < 0 || level > 9 ||
+        windowBits < 9 || windowBits > 15 || level < 0 || level > 9 ||
 	strategy < 0 || strategy > Z_HUFFMAN_ONLY) {
         return Z_STREAM_ERROR;
     }
@@ -3860,10 +3860,12 @@
                              &s->sub.trees.tb, z);
       if (t != Z_OK)
       {
-        ZFREE(z, s->sub.trees.blens);
         r = t;
         if (r == Z_DATA_ERROR)
+	{
+	  ZFREE(z, s->sub.trees.blens);
           s->mode = BADB;
+	}
         LEAVE
       }
       s->sub.trees.index = 0;
@@ -3928,11 +3930,13 @@
 #endif
         t = inflate_trees_dynamic(257 + (t & 0x1f), 1 + ((t >> 5) & 0x1f),
                                   s->sub.trees.blens, &bl, &bd, &tl, &td, z);
-        ZFREE(z, s->sub.trees.blens);
         if (t != Z_OK)
         {
           if (t == (uInt)Z_DATA_ERROR)
+	  {
+	    ZFREE(z, s->sub.trees.blens);
             s->mode = BADB;
+	  }
           r = t;
           LEAVE
         }
@@ -3945,6 +3949,7 @@
           r = Z_MEM_ERROR;
           LEAVE
         }
+        ZFREE(z, s->sub.trees.blens);
         s->sub.decode.codes = c;
         s->sub.decode.tl = tl;
         s->sub.decode.td = td;
diff -urN linux-2.4.19-pre3/fs/jffs2/zlib.c pmac/fs/jffs2/zlib.c
--- linux-2.4.19-pre3/fs/jffs2/zlib.c	Mon Sep 24 09:31:33 2001
+++ pmac/fs/jffs2/zlib.c	Tue Mar 19 15:46:47 2002
@@ -14,7 +14,7 @@
  */
 
 /* 
- *  ==FILEVERSION 971210==
+ *  ==FILEVERSION 20020318==
  *
  * This marker is used by the Linux installation script to determine
  * whether an up-to-date version of this file is already installed.
@@ -772,7 +772,7 @@
         windowBits = -windowBits;
     }
     if (memLevel < 1 || memLevel > MAX_MEM_LEVEL || method != Z_DEFLATED ||
-        windowBits < 8 || windowBits > 15 || level < 0 || level > 9 ||
+        windowBits < 9 || windowBits > 15 || level < 0 || level > 9 ||
 	strategy < 0 || strategy > Z_HUFFMAN_ONLY) {
         return Z_STREAM_ERROR;
     }
@@ -3860,10 +3860,12 @@
                              &s->sub.trees.tb, z);
       if (t != Z_OK)
       {
-        ZFREE(z, s->sub.trees.blens);
         r = t;
         if (r == Z_DATA_ERROR)
+	{
+	  ZFREE(z, s->sub.trees.blens);
           s->mode = BADB;
+	}
         LEAVE
       }
       s->sub.trees.index = 0;
@@ -3928,11 +3930,13 @@
 #endif
         t = inflate_trees_dynamic(257 + (t & 0x1f), 1 + ((t >> 5) & 0x1f),
                                   s->sub.trees.blens, &bl, &bd, &tl, &td, z);
-        ZFREE(z, s->sub.trees.blens);
         if (t != Z_OK)
         {
           if (t == (uInt)Z_DATA_ERROR)
+	  {
+	    ZFREE(z, s->sub.trees.blens);
             s->mode = BADB;
+	  }
           r = t;
           LEAVE
         }
@@ -3945,6 +3949,7 @@
           r = Z_MEM_ERROR;
           LEAVE
         }
+        ZFREE(z, s->sub.trees.blens);
         s->sub.decode.codes = c;
         s->sub.decode.tl = tl;
         s->sub.decode.td = td;

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-18 22:09     ` Paul Mackerras
@ 2002-03-19 10:45       ` David Woodhouse
  2002-03-19 13:53         ` David Woodhouse
  2002-03-19 18:06         ` H. Peter Anvin
  0 siblings, 2 replies; 25+ messages in thread
From: David Woodhouse @ 2002-03-19 10:45 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: J.A. Magallon, marcelo, linux-kernel

On Tue, 19 Mar 2002, Paul Mackerras wrote:

> David Woodhouse writes:
> 
> > After it's been in -ac for a while without mishap I'll ask Marcelo to
> > consider it - possibly for 2.4.20-pre1.
> 
> Yep, that sounds good to me.  For now, I think my patch should go in
> for 2.4.19.

Absolutely - sorry, I didn't mean to imply otherwise.

For the record - it's not worth bothering with fs/jffs2/zlib.c; if they 
can corrupt your file system on the medium, why bother with cracking zlib? 
:)

-- 
dwmw2


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-19 10:45       ` David Woodhouse
@ 2002-03-19 13:53         ` David Woodhouse
  2002-03-19 18:06         ` H. Peter Anvin
  1 sibling, 0 replies; 25+ messages in thread
From: David Woodhouse @ 2002-03-19 13:53 UTC (permalink / raw)
  To: David Woodhouse; +Cc: Paul Mackerras, J.A. Magallon, marcelo, linux-kernel

On Tue, 19 Mar 2002, David Woodhouse wrote:

> For the record - it's not worth bothering with fs/jffs2/zlib.c; if they 
> can corrupt your file system on the medium, why bother with cracking zlib? 
> :)

To preempt anyone else objecting to this...

I mean, given that we have a CRC on jffs2 nodes anyway, so the chances of
any accidentally corrupted input actually being fed to the decompressor
are virtually zero, it's not worth patching the 2.4.19 zlib when I want to
put the shared zlib into 2.4.20 anyway.

I'm not going to object to anyone else doing so, but I can't be bothered
to do it myself, as it would have virtually zero benefit and would mean
I'd have to update the shared-zlib patches for 2.4.

Infinitely more people (i.e. at least one) have been bitten by the fact
that you can't build both ppp_deflate and jffs2 into a 2.4 kernel.

-- 
dwmw2


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-19 10:45       ` David Woodhouse
  2002-03-19 13:53         ` David Woodhouse
@ 2002-03-19 18:06         ` H. Peter Anvin
  2002-03-19 19:14           ` Dave Jones
  2002-03-19 20:35           ` Nicolas Pitre
  1 sibling, 2 replies; 25+ messages in thread
From: H. Peter Anvin @ 2002-03-19 18:06 UTC (permalink / raw)
  To: linux-kernel

Followup to:  <Pine.LNX.4.44.0203191044150.26226-100000@passion.cambridge.redhat.com>
By author:    David Woodhouse <dwmw2@redhat.com>
In newsgroup: linux.dev.kernel
>
> On Tue, 19 Mar 2002, Paul Mackerras wrote:
> 
> > David Woodhouse writes:
> > 
> > > After it's been in -ac for a while without mishap I'll ask Marcelo to
> > > consider it - possibly for 2.4.20-pre1.
> > 
> > Yep, that sounds good to me.  For now, I think my patch should go in
> > for 2.4.19.
> 
> Absolutely - sorry, I didn't mean to imply otherwise.
> 
> For the record - it's not worth bothering with fs/jffs2/zlib.c; if they 
> can corrupt your file system on the medium, why bother with cracking zlib? 
> :)
> 

Removable media?

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-19 18:06         ` H. Peter Anvin
@ 2002-03-19 19:14           ` Dave Jones
  2002-03-19 19:36             ` H. Peter Anvin
  2002-03-19 20:35           ` Nicolas Pitre
  1 sibling, 1 reply; 25+ messages in thread
From: Dave Jones @ 2002-03-19 19:14 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: linux-kernel

 > > For the record - it's not worth bothering with fs/jffs2/zlib.c; if they 
 > > can corrupt your file system on the medium, why bother with cracking zlib? 
 > Removable media?

 If attacker has physical access to the media, there are far simpler
 ways of corrupting it than zlib exploitation. 8-)

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-19 19:14           ` Dave Jones
@ 2002-03-19 19:36             ` H. Peter Anvin
  2002-03-19 19:50               ` Dave Jones
  0 siblings, 1 reply; 25+ messages in thread
From: H. Peter Anvin @ 2002-03-19 19:36 UTC (permalink / raw)
  To: Dave Jones; +Cc: linux-kernel

Dave Jones wrote:

>  > > For the record - it's not worth bothering with fs/jffs2/zlib.c; if they 
>  > > can corrupt your file system on the medium, why bother with cracking zlib? 
>  > Removable media?
> 
>  If attacker has physical access to the media, there are far simpler
>  ways of corrupting it than zlib exploitation. 8-)
> 


Right, but you don't want someone to insert a removable medium and have
the system crash in response.
	
	-hpa



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-19 19:36             ` H. Peter Anvin
@ 2002-03-19 19:50               ` Dave Jones
  2002-03-19 19:59                 ` H. Peter Anvin
  0 siblings, 1 reply; 25+ messages in thread
From: Dave Jones @ 2002-03-19 19:50 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: linux-kernel

On Tue, Mar 19, 2002 at 11:36:19AM -0800, H. Peter Anvin wrote:

 > Right, but you don't want someone to insert a removable medium and have
 > the system crash in response.

 My understanding from one of dwmw2's earlier posts was that jffs2
 has crc's that would prevent this happening anyway (or at least make
 it nigh on impossible)
-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-19 19:50               ` Dave Jones
@ 2002-03-19 19:59                 ` H. Peter Anvin
  2002-03-19 20:09                   ` Dave Jones
  0 siblings, 1 reply; 25+ messages in thread
From: H. Peter Anvin @ 2002-03-19 19:59 UTC (permalink / raw)
  To: Dave Jones; +Cc: linux-kernel

Dave Jones wrote:

> On Tue, Mar 19, 2002 at 11:36:19AM -0800, H. Peter Anvin wrote:
> 
>  > Right, but you don't want someone to insert a removable medium and have
>  > the system crash in response.
> 
>  My understanding from one of dwmw2's earlier posts was that jffs2
>  has crc's that would prevent this happening anyway (or at least make
>  it nigh on impossible)
> 


I doubt that.  We're talking about corrupting the kernel VM.

	-hpa




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-19 19:59                 ` H. Peter Anvin
@ 2002-03-19 20:09                   ` Dave Jones
  0 siblings, 0 replies; 25+ messages in thread
From: Dave Jones @ 2002-03-19 20:09 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: linux-kernel

On Tue, Mar 19, 2002 at 11:59:07AM -0800, H. Peter Anvin wrote:

 > >  My understanding from one of dwmw2's earlier posts was that jffs2
 > >  has crc's that would prevent this happening anyway (or at least make
 > >  it nigh on impossible)
 > I doubt that.  We're talking about corrupting the kernel VM.

 Ignore me, I'm losing my mind.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-19 18:06         ` H. Peter Anvin
  2002-03-19 19:14           ` Dave Jones
@ 2002-03-19 20:35           ` Nicolas Pitre
  2002-03-20  9:45             ` Helge Hafting
  1 sibling, 1 reply; 25+ messages in thread
From: Nicolas Pitre @ 2002-03-19 20:35 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: lkml

On 19 Mar 2002, H. Peter Anvin wrote:

> Followup to:  <Pine.LNX.4.44.0203191044150.26226-100000@passion.cambridge.redhat.com>
> By author:    David Woodhouse <dwmw2@redhat.com>
> In newsgroup: linux.dev.kernel
> >
> > For the record - it's not worth bothering with fs/jffs2/zlib.c; if they 
> > can corrupt your file system on the medium, why bother with cracking zlib? 
> > :)
> > 
> 
> Removable media?

Most if not all removable media are not ment to be used with JFFS2.


Nicolas


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-19 20:35           ` Nicolas Pitre
@ 2002-03-20  9:45             ` Helge Hafting
  2002-03-20 14:45               ` Nicolas Pitre
  2002-03-20 15:59               ` Martin Hermanowski
  0 siblings, 2 replies; 25+ messages in thread
From: Helge Hafting @ 2002-03-20  9:45 UTC (permalink / raw)
  To: Nicolas Pitre, linux-kernel

Nicolas Pitre wrote:

> > Removable media?
> 
> Most if not all removable media are not ment to be used with JFFS2.

Nothing is _meant_ to be exploited either.  Someone could
create a cdrom with jffs2 (linux don't demand that cd's use iso9660)
with an intent to make trouble.  crc's and such would match the 
bad compressed stuff.  Nothing unusual seems to happen, but
using the cd installs a back door as the fs uncompresses stuff.

Helge Hafting

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-20  9:45             ` Helge Hafting
@ 2002-03-20 14:45               ` Nicolas Pitre
  2002-03-21 20:14                 ` H. Peter Anvin
  2002-03-20 15:59               ` Martin Hermanowski
  1 sibling, 1 reply; 25+ messages in thread
From: Nicolas Pitre @ 2002-03-20 14:45 UTC (permalink / raw)
  To: Helge Hafting; +Cc: linux-kernel

On Wed, 20 Mar 2002, Helge Hafting wrote:

> Nicolas Pitre wrote:
> 
> > > Removable media?
> > 
> > Most if not all removable media are not ment to be used with JFFS2.
> 
> Nothing is _meant_ to be exploited either.  Someone could
> create a cdrom with jffs2 (linux don't demand that cd's use iso9660)

But JFFS2 demands to be used with AN MTD device, not a block device.  And
most MTD device, if not all of them, on which JFFS2 is used aren't
removable.


Nicolas


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-20  9:45             ` Helge Hafting
  2002-03-20 14:45               ` Nicolas Pitre
@ 2002-03-20 15:59               ` Martin Hermanowski
  2002-03-20 16:17                 ` Tom Rini
  1 sibling, 1 reply; 25+ messages in thread
From: Martin Hermanowski @ 2002-03-20 15:59 UTC (permalink / raw)
  To: Helge Hafting; +Cc: Nicolas Pitre, linux-kernel

On Wed, Mar 20, 2002 at 10:45:42AM +0100, Helge Hafting wrote:
> Nicolas Pitre wrote:
> 
>>> Removable media?
>> 
>> Most if not all removable media are not ment to be used with JFFS2.
> 
> Nothing is _meant_ to be exploited either.  Someone could
> create a cdrom with jffs2 (linux don't demand that cd's use iso9660)
> with an intent to make trouble.  crc's and such would match the 
> bad compressed stuff.  Nothing unusual seems to happen, but
> using the cd installs a back door as the fs uncompresses stuff.

What about ZISOFS? IIRC the files are compressed with gzip und
decompressed on the fly.

MfG
Martin

-- 
PGP/GPG encrypted mail preferred, see header
,-- 
| Nur tote Fische schwimmen mit dem Strom
`--

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-20 15:59               ` Martin Hermanowski
@ 2002-03-20 16:17                 ` Tom Rini
  0 siblings, 0 replies; 25+ messages in thread
From: Tom Rini @ 2002-03-20 16:17 UTC (permalink / raw)
  To: Helge Hafting, Nicolas Pitre, linux-kernel

On Wed, Mar 20, 2002 at 04:59:33PM +0100, Martin Hermanowski wrote:
> On Wed, Mar 20, 2002 at 10:45:42AM +0100, Helge Hafting wrote:
> > Nicolas Pitre wrote:
> > 
> >>> Removable media?
> >> 
> >> Most if not all removable media are not ment to be used with JFFS2.
> > 
> > Nothing is _meant_ to be exploited either.  Someone could
> > create a cdrom with jffs2 (linux don't demand that cd's use iso9660)
> > with an intent to make trouble.  crc's and such would match the 
> > bad compressed stuff.  Nothing unusual seems to happen, but
> > using the cd installs a back door as the fs uncompresses stuff.
> 
> What about ZISOFS? IIRC the files are compressed with gzip und
> decompressed on the fly.

ZISOFS falls into the same case that 2.5 does.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-20 14:45               ` Nicolas Pitre
@ 2002-03-21 20:14                 ` H. Peter Anvin
  2002-03-21 21:03                   ` Tom Rini
  0 siblings, 1 reply; 25+ messages in thread
From: H. Peter Anvin @ 2002-03-21 20:14 UTC (permalink / raw)
  To: linux-kernel

Followup to:  <Pine.LNX.4.44.0203200943230.3615-100000@xanadu.home>
By author:    Nicolas Pitre <nico@cam.org>
In newsgroup: linux.dev.kernel
>
> On Wed, 20 Mar 2002, Helge Hafting wrote:
> 
> > Nicolas Pitre wrote:
> > 
> > > > Removable media?
> > > 
> > > Most if not all removable media are not ment to be used with JFFS2.
> > 
> > Nothing is _meant_ to be exploited either.  Someone could
> > create a cdrom with jffs2 (linux don't demand that cd's use iso9660)
> 
> But JFFS2 demands to be used with AN MTD device, not a block device.  And
> most MTD device, if not all of them, on which JFFS2 is used aren't
> removable.
> 

Isn't this whole discussion a bit silly?  If I'm not mistaken, we're
talking about a one-line known fix here...

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-21 20:14                 ` H. Peter Anvin
@ 2002-03-21 21:03                   ` Tom Rini
  2002-03-21 21:21                     ` Tom Rini
  2002-03-21 22:13                     ` Alan Cox
  0 siblings, 2 replies; 25+ messages in thread
From: Tom Rini @ 2002-03-21 21:03 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: linux-kernel

On Thu, Mar 21, 2002 at 12:14:33PM -0800, H. Peter Anvin wrote:
> Followup to:  <Pine.LNX.4.44.0203200943230.3615-100000@xanadu.home>
> By author:    Nicolas Pitre <nico@cam.org>
> In newsgroup: linux.dev.kernel
> >
> > On Wed, 20 Mar 2002, Helge Hafting wrote:
> > 
> > > Nicolas Pitre wrote:
> > > 
> > > > > Removable media?
> > > > 
> > > > Most if not all removable media are not ment to be used with JFFS2.
> > > 
> > > Nothing is _meant_ to be exploited either.  Someone could
> > > create a cdrom with jffs2 (linux don't demand that cd's use iso9660)
> > 
> > But JFFS2 demands to be used with AN MTD device, not a block device.  And
> > most MTD device, if not all of them, on which JFFS2 is used aren't
> > removable.
> 
> Isn't this whole discussion a bit silly?  If I'm not mistaken, we're
> talking about a one-line known fix here...

It's getting there.  The 'issue' is that the best way to fix it (maybe
2.4.20-pre1 even) is to backport the 2.5 zlib which doesn't have this
problem and removes most of the copies of zlib from the kernel.  If it's
not really a problem now, why fix it?  (Tho it should be a safe fix now
that Paul has produced a patch which doesn't suffer from random oopses
or other problems).

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-21 21:03                   ` Tom Rini
@ 2002-03-21 21:21                     ` Tom Rini
  2002-03-21 22:13                     ` Alan Cox
  1 sibling, 0 replies; 25+ messages in thread
From: Tom Rini @ 2002-03-21 21:21 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: linux-kernel

On Thu, Mar 21, 2002 at 02:03:56PM -0700, Tom Rini wrote:
> On Thu, Mar 21, 2002 at 12:14:33PM -0800, H. Peter Anvin wrote:
> > Followup to:  <Pine.LNX.4.44.0203200943230.3615-100000@xanadu.home>
> > By author:    Nicolas Pitre <nico@cam.org>
> > In newsgroup: linux.dev.kernel
> > >
> > > On Wed, 20 Mar 2002, Helge Hafting wrote:
> > > 
> > > > Nicolas Pitre wrote:
> > > > 
> > > > > > Removable media?
> > > > > 
> > > > > Most if not all removable media are not ment to be used with JFFS2.
> > > > 
> > > > Nothing is _meant_ to be exploited either.  Someone could
> > > > create a cdrom with jffs2 (linux don't demand that cd's use iso9660)
> > > 
> > > But JFFS2 demands to be used with AN MTD device, not a block device.  And
> > > most MTD device, if not all of them, on which JFFS2 is used aren't
> > > removable.
> > 
> > Isn't this whole discussion a bit silly?  If I'm not mistaken, we're
> > talking about a one-line known fix here...
> 
> It's getting there.

Correction, it is there since it's been fixed in 2.4.19-pre4 anyhow.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-21 21:03                   ` Tom Rini
  2002-03-21 21:21                     ` Tom Rini
@ 2002-03-21 22:13                     ` Alan Cox
  2002-03-22  0:06                       ` Corey Minyard
  1 sibling, 1 reply; 25+ messages in thread
From: Alan Cox @ 2002-03-21 22:13 UTC (permalink / raw)
  To: Tom Rini; +Cc: H. Peter Anvin, linux-kernel

> It's getting there.  The 'issue' is that the best way to fix it (maybe
> 2.4.20-pre1 even) is to backport the 2.5 zlib which doesn't have this

2.4.19ac has the shared zlib already. The zlib sharing stuff wasnt a 2.5
patch backported - its a 2.4 fix that went forward

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-21 22:13                     ` Alan Cox
@ 2002-03-22  0:06                       ` Corey Minyard
  2002-03-22  7:26                         ` David Woodhouse
  0 siblings, 1 reply; 25+ messages in thread
From: Corey Minyard @ 2002-03-22  0:06 UTC (permalink / raw)
  To: Alan Cox; +Cc: Tom Rini, H. Peter Anvin, linux-kernel

Alan Cox wrote:

>>It's getting there.  The 'issue' is that the best way to fix it (maybe
>>2.4.20-pre1 even) is to backport the 2.5 zlib which doesn't have this
>>
>
>2.4.19ac has the shared zlib already. The zlib sharing stuff wasnt a 2.5
>patch backported - its a 2.4 fix that went forward
>
Since I did the original shared zlib patch and I did it to 2.5, either 
we have two patches floating around or you are incorrect.  If we have 
two patches, we need to resolve the situation.

-Corey



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH] zlib double-free bug
  2002-03-22  0:06                       ` Corey Minyard
@ 2002-03-22  7:26                         ` David Woodhouse
  0 siblings, 0 replies; 25+ messages in thread
From: David Woodhouse @ 2002-03-22  7:26 UTC (permalink / raw)
  To: Corey Minyard; +Cc: Alan Cox, Tom Rini, H. Peter Anvin, linux-kernel


minyard@acm.org said:
> > 2.4.19ac has the shared zlib already. The zlib sharing stuff wasnt a
> > 2.5 patch backported - its a 2.4 fix that went forward

> Since I did the original shared zlib patch and I did it to 2.5, either
> we have two patches floating around or you are incorrect.  If we have 
> two patches, we need to resolve the situation. 

The patch that's now in the -ac tree is a backport of the 2.5 code, after we
actually made the 2.5 code _work_, that is.

Alan's right that there was at least _some_ work on a shared zlib in 2.4, 
though.


--
dwmw2



^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2002-03-22  7:30 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-18 10:57 [PATCH] zlib double-free bug Paul Mackerras
2002-03-18 14:49 ` J.A. Magallon
2002-03-18 15:15   ` Tom Rini
2002-03-18 16:36   ` David Woodhouse
2002-03-18 22:09     ` Paul Mackerras
2002-03-19 10:45       ` David Woodhouse
2002-03-19 13:53         ` David Woodhouse
2002-03-19 18:06         ` H. Peter Anvin
2002-03-19 19:14           ` Dave Jones
2002-03-19 19:36             ` H. Peter Anvin
2002-03-19 19:50               ` Dave Jones
2002-03-19 19:59                 ` H. Peter Anvin
2002-03-19 20:09                   ` Dave Jones
2002-03-19 20:35           ` Nicolas Pitre
2002-03-20  9:45             ` Helge Hafting
2002-03-20 14:45               ` Nicolas Pitre
2002-03-21 20:14                 ` H. Peter Anvin
2002-03-21 21:03                   ` Tom Rini
2002-03-21 21:21                     ` Tom Rini
2002-03-21 22:13                     ` Alan Cox
2002-03-22  0:06                       ` Corey Minyard
2002-03-22  7:26                         ` David Woodhouse
2002-03-20 15:59               ` Martin Hermanowski
2002-03-20 16:17                 ` Tom Rini
2002-03-19  5:01 ` Paul Mackerras

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).