From: Chris Wright Date: Thu, 11 Aug 2005 23:00:18 +0000 (-0700) Subject: Add some queued up patches (mostly security patches that were backlogged). X-Git-Tag: v2.6.12.6~11 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=68b3f72d29a5361edf40b0527873ebdfeffcd922;p=thirdparty%2Fkernel%2Fstable-queue.git Add some queued up patches (mostly security patches that were backlogged). --- diff --git a/queue/failed-keyring-oops.patch b/queue/failed-keyring-oops.patch new file mode 100644 index 00000000000..0419675fc9c --- /dev/null +++ b/queue/failed-keyring-oops.patch @@ -0,0 +1,48 @@ +From security-bounces@linux.kernel.org Wed Aug 3 05:19:40 2005 +From: David Howells +To: security@kernel.org +Date: Wed, 03 Aug 2005 13:19:07 +0100 +Subject: CAN-2005-2099 Destruction of failed keyring oopses + +The attached patch makes sure that a keyring that failed to instantiate +properly is destroyed without oopsing [CAN-2005-2099]. + +The problem occurs in three stages: + + (1) The key allocator initialises the type-specific data to all zeroes. In + the case of a keyring, this will become a link in the keyring name list + when the keyring is instantiated. + + (2) If a user (any user) attempts to add a keyring with anything other than + an empty payload, the keyring instantiation function will fail with an + error and won't add the keyring to the name list. + + (3) The keyring's destructor then sees that the keyring has a description + (name) and tries to remove the keyring from the name list, which oopses + because the link pointers are both zero. + +This bug permits any user to take down a box trivially. + +Signed-Off-By: David Howells +Signed-off-by: Chris Wright +--- + security/keys/keyring.c | 6 +++++- + 1 files changed, 5 insertions(+), 1 deletion(-) + +Index: linux-2.6.12.y/security/keys/keyring.c +=================================================================== +--- linux-2.6.12.y.orig/security/keys/keyring.c ++++ linux-2.6.12.y/security/keys/keyring.c +@@ -188,7 +188,11 @@ static void keyring_destroy(struct key * + + if (keyring->description) { + write_lock(&keyring_name_lock); +- list_del(&keyring->type_data.link); ++ ++ if (keyring->type_data.link.next != NULL && ++ !list_empty(&keyring->type_data.link)) ++ list_del(&keyring->type_data.link); ++ + write_unlock(&keyring_name_lock); + } + diff --git a/queue/key-session-join.patch b/queue/key-session-join.patch new file mode 100644 index 00000000000..13bfcbe33a2 --- /dev/null +++ b/queue/key-session-join.patch @@ -0,0 +1,48 @@ +From security-bounces@linux.kernel.org Wed Aug 3 05:19:32 2005 +From: David Howells +To: security@kernel.org +Date: Wed, 03 Aug 2005 13:19:03 +0100 +Cc: +Subject: CAN-2005-2098 Error during attempt to join key management session can leave semaphore pinned + +The attached patch prevents an error during the key session joining operation +from hanging future joins in the D state [CAN-2005-2098]. + +The problem is that the error handling path for the KEYCTL_JOIN_SESSION_KEYRING +operation has one error path that doesn't release the session management +semaphore. Further attempts to get the semaphore will then sleep for ever in +the D state. + +This can happen in four situations, all involving an attempt to allocate a new +session keyring: + + (1) ENOMEM. + + (2) The users key quota being reached. + + (3) A keyring name that is an empty string. + + (4) A keyring name that is too long. + +Any user may attempt this operation, and so any user can cause the problem to +occur. + +Signed-Off-By: David Howells +Signed-off-by: Chris Wright +--- + security/keys/process_keys.c | 2 +- + 1 files changed, 1 insertion(+), 1 deletion(-) + +Index: linux-2.6.12.y/security/keys/process_keys.c +=================================================================== +--- linux-2.6.12.y.orig/security/keys/process_keys.c ++++ linux-2.6.12.y/security/keys/process_keys.c +@@ -641,7 +641,7 @@ long join_session_keyring(const char *na + keyring = keyring_alloc(name, tsk->uid, tsk->gid, 0, NULL); + if (IS_ERR(keyring)) { + ret = PTR_ERR(keyring); +- goto error; ++ goto error2; + } + } + else if (IS_ERR(keyring)) { diff --git a/queue/linux-zlib-fixes.patch b/queue/linux-zlib-fixes.patch new file mode 100644 index 00000000000..90bd5eea0cb --- /dev/null +++ b/queue/linux-zlib-fixes.patch @@ -0,0 +1,95 @@ +From security-bounces@linux.kernel.org Mon Jul 25 15:16:42 2005 +Date: Mon, 25 Jul 2005 23:16:13 +0100 +From: Tim Yamin +To: security@kernel.org +Subject: [PATCH] Update in-kernel zlib routines + +Fix outstanding security bugs in the Linux zlib implementations. See: + +a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html +b) http://bugs.gentoo.org/show_bug.cgi?id=94584 + +Signed-off-by: Tim Yamin +Signed-off-by: Tavis Ormandy +Signed-off-by: Chris Wright +--- + arch/ppc64/boot/zlib.c | 3 ++- + lib/inflate.c | 16 +++++++++------- + lib/zlib_inflate/inftrees.c | 2 +- + 3 files changed, 12 insertions(+), 9 deletions(-) + +Index: linux-2.6.12.y/lib/inflate.c +=================================================================== +--- linux-2.6.12.y.orig/lib/inflate.c ++++ linux-2.6.12.y/lib/inflate.c +@@ -326,7 +326,7 @@ DEBG("huft1 "); + { + *t = (struct huft *)NULL; + *m = 0; +- return 0; ++ return 2; + } + + DEBG("huft2 "); +@@ -374,6 +374,7 @@ DEBG("huft5 "); + if ((j = *p++) != 0) + v[x[j]++] = i; + } while (++i < n); ++ n = x[g]; /* set n to length of v */ + + DEBG("h6 "); + +@@ -410,12 +411,13 @@ DEBG1("1 "); + DEBG1("2 "); + f -= a + 1; /* deduct codes from patterns left */ + xp = c + k; +- while (++j < z) /* try smaller tables up to z bits */ +- { +- if ((f <<= 1) <= *++xp) +- break; /* enough codes to use up j bits */ +- f -= *xp; /* else deduct codes from patterns */ +- } ++ if (j < z) ++ while (++j < z) /* try smaller tables up to z bits */ ++ { ++ if ((f <<= 1) <= *++xp) ++ break; /* enough codes to use up j bits */ ++ f -= *xp; /* else deduct codes from patterns */ ++ } + } + DEBG1("3 "); + z = 1 << j; /* table entries for j-bit table */ +Index: linux-2.6.12.y/lib/zlib_inflate/inftrees.c +=================================================================== +--- linux-2.6.12.y.orig/lib/zlib_inflate/inftrees.c ++++ linux-2.6.12.y/lib/zlib_inflate/inftrees.c +@@ -141,7 +141,7 @@ static int huft_build( + { + *t = NULL; + *m = 0; +- return Z_OK; ++ return Z_DATA_ERROR; + } + + +Index: linux-2.6.12.y/arch/ppc64/boot/zlib.c +=================================================================== +--- linux-2.6.12.y.orig/arch/ppc64/boot/zlib.c ++++ linux-2.6.12.y/arch/ppc64/boot/zlib.c +@@ -1307,7 +1307,7 @@ local int huft_build( + { + *t = (inflate_huft *)Z_NULL; + *m = 0; +- return Z_OK; ++ return Z_DATA_ERROR; + } + + +@@ -1351,6 +1351,7 @@ local int huft_build( + if ((j = *p++) != 0) + v[x[j]++] = i; + } while (++i < n); ++ n = x[g]; /* set n to length of v */ + + + /* Generate the Huffman codes and for each, make the table entries */ diff --git a/queue/module-per-cpu-alignment-fix.patch b/queue/module-per-cpu-alignment-fix.patch new file mode 100644 index 00000000000..6c94079c255 --- /dev/null +++ b/queue/module-per-cpu-alignment-fix.patch @@ -0,0 +1,77 @@ +From stable-bounces@linux.kernel.org Wed Aug 10 05:52:08 2005 +Date: Wed, 10 Aug 2005 13:52:38 +0100 +From: Daniel Drake +To: stable@kernel.org +Cc: rusty@rustcorp.com.au +Subject: [PATCH] Module per-cpu alignment cannot always be met + +From: Rusty Russell + +[PATCH] Module per-cpu alignment cannot always be met + +The module code assumes noone will ever ask for a per-cpu area more than +SMP_CACHE_BYTES aligned. However, as these cases show, gcc asks sometimes +asks for 32-byte alignment for the per-cpu section on a module, and if +CONFIG_X86_L1_CACHE_SHIFT is 4, we hit that BUG_ON(). This is obviously an +unusual combination, as there have been few reports, but better to warn +than die. + +See: + http://www.ussg.iu.edu/hypermail/linux/kernel/0409.0/0768.html + +And more recently: + http://bugs.gentoo.org/show_bug.cgi?id=97006 + +Signed-off-by: Rusty Russell +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Chris Wright +--- + kernel/module.c | 15 +++++++++++---- + 1 files changed, 11 insertions(+), 4 deletions(-) + +Index: linux-2.6.12.y/kernel/module.c +=================================================================== +--- linux-2.6.12.y.orig/kernel/module.c ++++ linux-2.6.12.y/kernel/module.c +@@ -249,13 +249,18 @@ static inline unsigned int block_size(in + /* Created by linker magic */ + extern char __per_cpu_start[], __per_cpu_end[]; + +-static void *percpu_modalloc(unsigned long size, unsigned long align) ++static void *percpu_modalloc(unsigned long size, unsigned long align, ++ const char *name) + { + unsigned long extra; + unsigned int i; + void *ptr; + +- BUG_ON(align > SMP_CACHE_BYTES); ++ if (align > SMP_CACHE_BYTES) { ++ printk(KERN_WARNING "%s: per-cpu alignment %li > %i\n", ++ name, align, SMP_CACHE_BYTES); ++ align = SMP_CACHE_BYTES; ++ } + + ptr = __per_cpu_start; + for (i = 0; i < pcpu_num_used; ptr += block_size(pcpu_size[i]), i++) { +@@ -347,7 +352,8 @@ static int percpu_modinit(void) + } + __initcall(percpu_modinit); + #else /* ... !CONFIG_SMP */ +-static inline void *percpu_modalloc(unsigned long size, unsigned long align) ++static inline void *percpu_modalloc(unsigned long size, unsigned long align, ++ const char *name) + { + return NULL; + } +@@ -1554,7 +1560,8 @@ static struct module *load_module(void _ + if (pcpuindex) { + /* We have a special allocation for this section. */ + percpu = percpu_modalloc(sechdrs[pcpuindex].sh_size, +- sechdrs[pcpuindex].sh_addralign); ++ sechdrs[pcpuindex].sh_addralign, ++ mod->name); + if (!percpu) { + err = -ENOMEM; + goto free_mod; diff --git a/queue/series b/queue/series index 63bea367600..7c19765694e 100644 --- a/queue/series +++ b/queue/series @@ -1,3 +1,8 @@ sys_set_mempolicy-mode-check.patch x86_64-srat-dual-core-amd.patch x86_64-fix-smpboot-timing-problem.patch +linux-zlib-fixes.patch +zisofs.patch +key-session-join.patch +failed-keyring-oops.patch +module-per-cpu-alignment-fix.patch diff --git a/queue/zisofs.patch b/queue/zisofs.patch new file mode 100644 index 00000000000..c5ae15b35e6 --- /dev/null +++ b/queue/zisofs.patch @@ -0,0 +1,60 @@ +From torvalds@osdl.org Sat Aug 6 11:33:12 2005 +Date: Sat, 6 Aug 2005 11:33:11 -0700 (PDT) +From: Linus Torvalds +To: Tim Yamin +cc: "H. Peter Anvin" , Chris Wright , + security@kernel.org +Subject: Check input buffer size in zisofs + +Add fakey 'deflateBound()' function to the in-kernel zlib routines + +It's not the real deflateBound() in newer zlib libraries, partly because +the upcoming usage of it won't have the "stream" available, so we can't +have the same interfaces anyway. + +This uses the new deflateBound() thing to sanity-check the input to the +zlib decompressor before we even bother to start reading in the blocks. + +Problem noted by Tim Yamin + +Signed-off-by: Chris Wright +--- + fs/isofs/compress.c | 6 ++++++ + include/linux/zlib.h | 5 +++++ + 2 files changed, 11 insertions(+) + +Index: linux-2.6.12.y/include/linux/zlib.h +=================================================================== +--- linux-2.6.12.y.orig/include/linux/zlib.h ++++ linux-2.6.12.y/include/linux/zlib.h +@@ -506,6 +506,11 @@ extern int zlib_deflateReset (z_streamp + stream state was inconsistent (such as zalloc or state being NULL). + */ + ++static inline unsigned long deflateBound(unsigned long s) ++{ ++ return s + ((s + 7) >> 3) + ((s + 63) >> 6) + 11; ++} ++ + extern int zlib_deflateParams (z_streamp strm, int level, int strategy); + /* + Dynamically update the compression level and compression strategy. The +Index: linux-2.6.12.y/fs/isofs/compress.c +=================================================================== +--- linux-2.6.12.y.orig/fs/isofs/compress.c ++++ linux-2.6.12.y/fs/isofs/compress.c +@@ -129,8 +129,14 @@ static int zisofs_readpage(struct file * + cend = le32_to_cpu(*(__le32 *)(bh->b_data + (blockendptr & bufmask))); + brelse(bh); + ++ if (cstart > cend) ++ goto eio; ++ + csize = cend-cstart; + ++ if (csize > deflateBound(1UL << zisofs_block_shift)) ++ goto eio; ++ + /* Now page[] contains an array of pages, any of which can be NULL, + and the locks on which we hold. We should now read the data and + release the pages. If the pages are NULL the decompressed data