linux-stable.git/drivers/char, branch linux-2.6.29.y

pcmcia/cm4000: fix lock imbalance

2009-07-02T23:40:55+00:00

commit 69ae59d7d8df14413cf0a97b3e372d7dc8352563 upstream.

Don't return from switch/case, break instead, so that we unlock BKL.

Signed-off-by: Jiri Slaby 
Signed-off-by: Alan Cox 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

vt_ioctl: fix lock imbalance

2009-07-02T23:40:50+00:00

commit a115902f67ef51fbbe83e214fb761aaa9734c1ce upstream.

Don't return from switch/case directly in vt_ioctl. Set ret and break
instead so that we unlock BKL.

Signed-off-by: Jiri Slaby 
Signed-off-by: Alan Cox 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

char: moxa, prevent opening unavailable ports

2009-07-02T23:40:40+00:00

commit a90b037583d5f1ae3e54e9c687c79df82d1d34a4 upstream.

In moxa.c there are 32 minor numbers reserved for each device.  The number
of ports actually available per device is stored in
moxa_board_conf->numPorts.  This number is not considered in moxa_open().
Opening a port that is not available results in a kernel oops.  This patch
adds a test to moxa_open() that prevents opening unavailable ports.

[akpm@linux-foundation.org: avoid multiple returns]
Signed-off-by: Dirk Eibach 
Signed-off-by: Jiri Slaby 
Cc: Alan Cox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

char: mxser, fix ISA board lookup

2009-07-02T23:40:30+00:00

commit 96050dfb25966612008dcea7d342e91fa01e993c upstream.

There's a bug in the mxser kernel module that still appears in the
2.6.29.4 kernel.

mxser_get_ISA_conf takes a ioaddress as its first argument, by passing the
not of the ioaddr, you're effectively passing 0 which means it won't be
able to talk to an ISA card.  I have tested this, and removing the !
fixes the problem.

Cc: "Peter Botha" 
Signed-off-by: Jiri Slaby 
Acked-by: Alan Cox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Avoid ICE in get_random_int() with gcc-3.4.5

2009-06-15T16:40:14+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-15T16:40:13+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-15T16:40:00+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-08T22:45:00+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

agp: zero pages before sending to userspace

2009-04-27T17:37:05+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

Revert "console ASCII glyph 1:1 mapping"

2009-04-27T17:37:04+00:00

upstream commit: c0b7988200a82290287c6f4cd49585007f73175a

This reverts commit 1c55f18717304100a5f624c923f7cb6511b4116d.

Ingo Brueckl was assuming that reverting to 1:1 mapping for chars >= 128
was not useful, but it happens to be: due to the limitations of the
Linux console, when a blind user wants to read BIG5 on it, he has no
other way than loading a font without SFM and let the 1:1 mapping permit
the screen reader to get the BIG5 encoding.

Signed-off-by: Samuel Thibault 
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright