linux, branch v2.6.12.5

Linux 2.6.12.5

2005-08-15T00:20:18Z

[PATCH] Module per-cpu alignment cannot always be met

2005-08-15T00:20:11Z

Fwd from Daniel Drake . 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 Signed-off-by: Greg Kroah-Hartman

[PATCH] CAN-2005-2099 Destruction of failed keyring oopses

2005-08-15T00:20:10Z

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 Signed-off-by: Greg Kroah-Hartman

[PATCH] CAN-2005-2098 Error during attempt to join key management session can leave semaphore pinned

2005-08-15T00:20:10Z

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 Signed-off-by: Greg Kroah-Hartman

[PATCH] Check input buffer size in zisofs

2005-08-15T00:20:09Z

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 Signed-off-by: Greg Kroah-Hartman Signed-off-by: H. Peter Anvin

[PATCH] Update in-kernel zlib routines (CAN-2005-2458, CAN-2005-2459)

2005-08-15T00:20:09Z

Fix outstanding security bugs in the Linux zlib implementations. See: a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html CAN-2005-2458 b) http://bugs.gentoo.org/show_bug.cgi?id=94584 CAN-2005-2459 Signed-off-by: Tim Yamin Signed-off-by: Tavis Ormandy Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] x86_64: Fixing smpboot timing problem

2005-08-15T00:20:08Z

This patch fixes the SMP boot timing problem that hit various people and was introduced in 2.6.12. Please apply to stable. >From Eric Biederman sync_tsc was using smp_call_function to ask the boot processor to report it's tsc value. smp_call_function performs an IPI_send_allbutself which is a broadcast ipi. There is a window during processor startup during which the target cpu has started and before it has initialized it's interrupt vectors so it can properly process an interrupt. Receveing an interrupt during that window will triple fault the cpu and do other nasty things. Why cli does not protect us from that is beyond me. The simple fix is to match ia64 and provide a smp_call_function_single. Which avoids the broadcast and is more efficient. This certainly fixes the problem of getting stuck on boot which was very easy to trigger on my SMP Hyperthreaded Xeon, and I think it fixes it for the right reasons. Signed-off-by: "Eric W. Biederman" Signed-off-by: Andi Kleen Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] Fix SRAT for non dual core AMD systems

2005-08-15T00:20:08Z

Patch for 2.6.12-STABLE This fixes a bug in SRAT handling on AMD systems that was introduced with the dual core support. It would be disabled on CPUs without dual core. Just drop the bogus check. Signed-off-by: Andi Kleen Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] sys_set_mempolicy() doesnt check if mode < 0

2005-08-15T00:20:07Z

A kernel BUG() is triggered by a call to set_mempolicy() with a negative first argument. This is because the mode is declared as an int, and the validity check doesnt check < 0 values. Alternatively, mode could be declared as unsigned int or unsigned long. Signed-off-by: Eric Dumazet Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

Linux 2.6.12.4

2005-08-05T07:04:37Z