linux-toradex.git/drivers, branch v2.6.25.20

ACPI: video: fix brightness allocation

2008-11-10T18:50:07+00:00

Thanks to Arjan for spotting this for .stable:
http://www.kerneloops.org/search.php?search=acpi_video_switch_brightness

upstream commit 469778c1740fcf3113498b6fdf4559bdec25c58f

ACPI: video: fix brightness allocation

Fix use of uninitialized device->brightness.

Signed-off-by: Julia Jomantaite 
Signed-off-by: Andi Kleen 
Acked-by: Zhang Rui 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

ACPI: dock: avoid check _STA method

2008-11-10T18:50:06+00:00

commit 8b59560a3baf2e7c24e0fb92ea5d09eca92805db upstream.

ACPI: dock: avoid check _STA method

In some BIOSes, every _STA method call will send a notification again,
this cause freeze. And in some BIOSes, it appears _STA should be called
after _DCK. This tries to avoid calls _STA, and still keep the device
present check.

http://bugzilla.kernel.org/show_bug.cgi?id=10431

Signed-off-by: Shaohua Li 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

libertas: fix buffer overrun

2008-11-10T18:50:05+00:00

commit 48735d8d8bd701b1e0cd3d49c21e5e385ddcb077 upstream

If somebody sends an invalid beacon/probe response, that can trash the
whole BSS descriptor. The descriptor is, luckily, large enough so that
it cannot scribble past the end of it; it's well above 400 bytes long.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

edac cell: fix incorrect edac_mode

2008-11-10T18:50:05+00:00

commit 3b274f44d2ca05f719fe39947b6a5293a2dbd8fd upstream

The cell_edac driver is setting the edac_mode field of the csrow's to an
incorrect value, causing the sysfs show routine for that field to go out
of an array bound and Oopsing the kernel when used.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Doug Thompson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

gpiolib: fix oops in gpio_get_value_cansleep()

2008-11-10T18:50:04+00:00

commit 978ccaa8ea5d8c7bf6b676209f2fc126eae6355b upstream

We can get the following oops from gpio_get_value_cansleep() when a GPIO
controller doesn't provide a get() callback:

 Unable to handle kernel paging request for instruction fetch
 Faulting instruction address: 0x00000000
 Oops: Kernel access of bad area, sig: 11 [#1]
 [...]
 NIP [00000000] 0x0
 LR [c0182fb0] gpio_get_value_cansleep+0x40/0x50
 Call Trace:
 [c7b79e80] [c0183f28] gpio_value_show+0x5c/0x94
 [c7b79ea0] [c01a584c] dev_attr_show+0x30/0x7c
 [c7b79eb0] [c00d6b48] fill_read_buffer+0x68/0xe0
 [c7b79ed0] [c00d6c54] sysfs_read_file+0x94/0xbc
 [c7b79ef0] [c008f24c] vfs_read+0xb4/0x16c
 [c7b79f10] [c008f580] sys_read+0x4c/0x90
 [c7b79f40] [c0013a14] ret_from_syscall+0x0/0x38

It's OK to request the value of *any* GPIO; most GPIOs are bidirectional,
so configuring them as outputs just enables an output driver and doesn't
disable the input logic.

So the problem is that gpio_get_value_cansleep() isn't making the same
sanity check that gpio_get_value() does: making sure this GPIO isn't one
of the atypical "no input logic" cases.

Reported-by: Anton Vorontsov 
Signed-off-by: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

security: avoid calling a NULL function pointer in drivers/video/tvaudio.c

2008-10-22T21:05:18+00:00

commit 5ba2f67afb02c5302b2898949ed6fc3b3d37dcf1 upstream

NULL function pointers are very bad security wise. This one got caught by
kerneloops.org quite a few times, so it's happening in the field....

Fix is simple, check the function pointer for NULL, like 6 other places
in the same function are already doing.

Signed-off-by: Arjan van de Ven 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

drm/i915: fix ioremap of a user address for non-root (CVE-2008-3831)

2008-10-22T21:05:16+00:00

commit 4b40893918203ee1a1f6a114316c2a19c072e9bd upstream

Olaf Kirch noticed that the i915_set_status_page() function of the i915
kernel driver calls ioremap with an address offset that is supplied by
userspace via ioctl. The function zeroes the mapped memory via memset
and tells the hardware about the address. Turns out that access to that
ioctl is not restricted to root so users could probably exploit that to
do nasty things. We haven't tried to write actual exploit code though.

It only affects the Intel G33 series and newer.

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

V4L: zr36067: Fix RGBR pixel format

2008-10-22T21:05:16+00:00

(cherry picked from commit a30ee3c747728f9151664118ffcbdeefd202c332)

The zr36067 driver is improperly declaring pixel format RGBP twice,
once as "16-bit RGB LE" and once as "16-bit RGB BE". The latter is
actually RGBR. Fix the code to properly map both pixel formats.

Signed-off-by: Jean Delvare 
Acked-by: Trent Piepho 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Michael Krufky 
Signed-off-by: Greg Kroah-Hartman

V4L: bttv: Prevent NULL pointer dereference in radio_open

2008-10-22T21:05:16+00:00

cherry picked from commit c37396c19403e249f12626187d51e92c915f2bc9

Fix the following crash in the bttv driver:

BUG: unable to handle kernel NULL pointer dereference at 000000000000036c
IP: [] radio_open+0x3a/0x170 [bttv]

This happens because radio_open assumes that all present bttv devices
have a radio function. If a bttv device without radio and one with
radio are installed on the same system, and the one without radio is
registered first, then radio_open checks for the radio device number
of a bttv device that has no radio function, and this breaks. All we
have to do to fix it is to skip bttv devices without a radio function.

Signed-off-by: Jean Delvare 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Michael Krufky 
Signed-off-by: Greg Kroah-Hartman

hwmon: (it87) Prevent power-off on Shuttle SN68PT

2008-10-22T21:05:15+00:00

based on commit 98dd22c3e086d76058083432d4d8fb85f04bab90 upstream

On the Shuttle SN68PT, FAN_CTL2 is apparently not connected to a fan,
but to something else. One user has reported instant system power-off
when changing the PWM2 duty cycle, so we disable it.

I use the board name string as the trigger in case the same board is
ever used in other systems.

This closes lm-sensors ticket #2349:
pwmconfig causes a hard poweroff
http://www.lm-sensors.org/ticket/2349

Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman