linux-toradex.git/drivers/char, branch v2.6.27.25

Avoid ICE in get_random_int() with gcc-3.4.5

2009-06-12T03:01:27+00:00

commit 26a9a418237c0b06528941bca693c49c8d97edbe upstream.

Martin Knoblauch reports that trying to build 2.6.30-rc6-git3 with
RHEL4.3 userspace (gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)) causes an
internal compiler error (ICE):

    drivers/char/random.c: In function `get_random_int':
    drivers/char/random.c:1672: error: unrecognizable insn:
    (insn 202 148 150 0 /scratch/build/linux-2.6.30-rc6-git3/arch/x86/include/asm/tsc.h:23 (set (reg:SI 0 ax [91])
            (subreg:SI (plus:DI (plus:DI (reg:DI 0 ax [88])
                        (subreg:DI (reg:SI 6 bp) 0))
                    (const_int -4 [0xfffffffffffffffc])) 0)) -1 (nil)
        (nil))
    drivers/char/random.c:1672: internal compiler error: in extract_insn, at recog.c:2083

and after some debugging it turns out that it's due to the code trying
to figure out the rough value of the current stack pointer by taking an
address of an uninitialized variable and casting that to an integer.

This is clearly a compiler bug, but it's not worth fighting - while the
current stack kernel pointer might be somewhat hard to predict in user
space, it's also not generally going to change for a lot of the call
chains for a particular process.

So just drop it, and mumble some incoherent curses at the compiler.

Tested-by: Martin Knoblauch 
Cc: Matt Mackall 
Cc: Ingo Molnar 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

random: make get_random_int() more random

2009-06-12T03:01:27+00:00

commit 8a0a9bd4db63bc45e3017bedeafbd88d0eb84d02 upstream.

It's a really simple patch that basically just open-codes the current
"secure_ip_id()" call, but when open-coding it we now use a _static_
hashing area, so that it gets updated every time.

And to make sure somebody can't just start from the same original seed of
all-zeroes, and then do the "half_md4_transform()" over and over until
they get the same sequence as the kernel has, each iteration also mixes in
the same old "current->pid + jiffies" we used - so we should now have a
regular strong pseudo-number generator, but we also have one that doesn't
have a single seed.

Note: the "pid + jiffies" is just meant to be a tiny tiny bit of noise. It
has no real meaning. It could be anything. I just picked the previous
seed, it's just that now we keep the state in between calls and that will
feed into the next result, and that should make all the difference.

I made that hash be a per-cpu data just to avoid cache-line ping-pong:
having multiple CPU's write to the same data would be fine for randomness,
and add yet another layer of chaos to it, but since get_random_int() is
supposed to be a fast interface I did it that way instead. I considered
using "__raw_get_cpu_var()" to avoid any preemption overhead while still
getting the hash be _mostly_ ping-pong free, but in the end good taste won
out.

Signed-off-by: Ingo Molnar 
Signed-off-by: Linus Torvalds 
Cc: Jake Edge 
Signed-off-by: Greg Kroah-Hartman

TPM: get_event_name stack corruption

2009-06-12T03:01:08+00:00

commit fbaa58696cef848de818768783ef185bd3f05158 upstream.

get_event_name uses sprintf to fill a buffer declared on the stack.  It fills
the buffer 2 bytes at a time.  What the code doesn't take into account is that
sprintf(buf, "%02x", data) actually writes 3 bytes.  2 bytes for the data and
then it nul terminates the string.  Since we declare buf to be 40 characters
long and then we write 40 bytes of data into buf sprintf is going to write 41
characters.  The fix is to leave room in buf for the nul terminator.

Signed-off-by: Eric Paris 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

virtio-rng: Remove false BUG for spurious callbacks

2009-05-08T21:54:33+00:00

upstream commit: e5b89542ea18020961882228c26db3ba87f6e608

The virtio-rng drivers checks for spurious callbacks. Since
callbacks can be implemented via shared interrupts (e.g. PCI) this
could lead to guest kernel oopses with lots of virtio devices.

Signed-off-by: Christian Borntraeger 
Cc: Rusty Russell 
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

agp: zero pages before sending to userspace

2009-05-02T17:24:33+00:00

upstream commit: 59de2bebabc5027f93df999d59cc65df591c3e6e

CVE-2009-1192

AGP pages might be mapped into userspace finally, so the pages should be
set to zero before userspace can use it. Otherwise there is potential
information leakage.

Signed-off-by: Shaohua Li 
Signed-off-by: Dave Airlie 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

Add a missing unlock_kernel() in raw_open()

2009-05-02T17:23:37+00:00

upstream commit: 996ff68d8b358885c1de82a45517c607999947c7

Cc: stable@kernel.org
Signed-off-by: Dan Carpenter 
Signed-off-by: Jonathan Corbet 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

intel-agp: fix a panic with 1M of shared memory, no GTT entries

2009-03-17T00:52:53+00:00

commit 9c1e8a4ebcc04226cb6f3a1bf1d72f4cafd6b089 upstream.

When GTT size is equal to amount of video memory, the amount of GTT
entries is computed lower than zero, which is invalid and leads to
off-by-one error in intel_i915_configure()

Originally posted here:
http://bugzilla.kernel.org/show_bug.cgi?id=12539
http://bugzilla.redhat.com/show_bug.cgi?id=445592

Signed-off-by: Lubomir Rintel 
Cc: Lubomir Rintel 
Cc: Dave Airlie 
Reviewed-by: Eric Anholt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Revert "vt: fix background color on line feed"

2009-02-12T17:31:12+00:00

commit 93f78da405685a756beeaeae4b5e41fcec39eab3 upstream.

This reverts commit c9e587abfdec2c2aaa55fab83bcb4972e2f84f9b, and the
subsequent commits that fixed it up:

 - afa9b649 "fbcon: prevent cursor disappearance after switching to 512
   character font"

 - d850a2fa "vt/fbcon: fix background color on line feed"

 - 7fe3915a "vt/fbcon: update scrl_erase_char after 256/512-glyph font
   switch"

by request of Alan Cox. Quoth Alan:
  "Unfortunately it's wrong and its been causing breakages because
   various apps like ncurses expect our previous (and correct)
   behaviour."

Alexander sent out a similar patch.

Requested-by: Alan Cox 
Tested-by: Jan Engelhardt 
Cc: Alexander V. Lukyanov 
Signed-off-by: Linus Torvalds 
Cc: Tony Jones 
Signed-off-by: Greg Kroah-Hartman

agp/intel: Reduce extraneous PCI posting reads during init

2009-02-12T17:31:00+00:00

commit 44d494417278e49f5b42bd3ded1801b6d2254db8 upstream.

Instead of doing a posting read after each GTT entry update, do a single one
at the end of the writes. This should reduce boot time a tiny amount by
avoiding a lot of extra uncached reads.

Signed-off-by: Keith Packard 
Signed-off-by: Eric Anholt 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

agp/intel: Fix broken ® symbol in device name.

2009-02-12T17:31:00+00:00

commit b854b2ab959e8175d75e01cf8ed452ed2624d0c8 upstream.

Signed-off-by: Eric Anholt 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman