Vitaly Kuznetsov [Tue, 14 Dec 2010 15:16:49 +0000 (10:16 -0500)]
USB: usb-storage: unusual_devs entry for the Samsung YP-CP3
commit
d73a9b3001f29271c2e9f2a806b05a431c5d9591 upstream.
Add an unusual_devs entry for the Samsung YP-CP3 MP4 player.
User was getting the following errors in dmesg:
usb 2-6: reset high speed USB device using ehci_hcd and address 2
usb 2-6: reset high speed USB device using ehci_hcd and address 2
usb 2-6: reset high speed USB device using ehci_hcd and address 2
usb 2-6: USB disconnect, address 2
sd 3:0:0:0: [sdb] Assuming drive cache: write through
sdb:<2>ldm_validate_partition_table(): Disk read failed.
Dev sdb: unable to read RDB block 0
unable to read partition table
Signed-off-by: Vitaly Kuznetsov <vitty@altlinux.ru>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Florian Faber [Wed, 1 Dec 2010 09:11:08 +0000 (10:11 +0100)]
USB: ftdi_sio: Add D.O.Tec PID
commit
5363cdc3c5da9bd431552cf5989ab481596f0c6d upstream.
Add FTDI PID to identify D.O.Tec devices correctly.
Signed-off-by: Florian Faber <faberman@linuxproaudio.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Sailer [Tue, 14 Dec 2010 15:04:05 +0000 (16:04 +0100)]
USB: misc: uss720.c: add another vendor/product ID
commit
ecc1624a2fff45780959efbcb73ace18fdb3c58d upstream.
Fabio Battaglia report that he has another cable that works with this
driver, so this patch adds its vendor/product ID.
Signed-off-by: Thomas Sailer <t.sailer@alumni.ethz.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tavis Ormandy [Thu, 9 Dec 2010 14:29:42 +0000 (15:29 +0100)]
install_special_mapping skips security_file_mmap check.
commit
462e635e5b73ba9a4c03913b77138cd57ce4b050 upstream.
The install_special_mapping routine (used, for example, to setup the
vdso) skips the security check before insert_vm_struct, allowing a local
attacker to bypass the mmap_min_addr security restriction by limiting
the available pages for special mappings.
bprm_mm_init() also skips the check, and although I don't think this can
be used to bypass any restrictions, I don't see any reason not to have
the security check.
$ uname -m
x86_64
$ cat /proc/sys/vm/mmap_min_addr
65536
$ cat install_special_mapping.s
section .bss
resb BSS_SIZE
section .text
global _start
_start:
mov eax, __NR_pause
int 0x80
$ nasm -D__NR_pause=29 -DBSS_SIZE=0xfffed000 -f elf -o install_special_mapping.o install_special_mapping.s
$ ld -m elf_i386 -Ttext=0x10000 -Tbss=0x11000 -o install_special_mapping install_special_mapping.o
$ ./install_special_mapping &
[1] 14303
$ cat /proc/14303/maps
0000f000-
00010000 r-xp
00000000 00:00 0 [vdso]
00010000-
00011000 r-xp
00001000 00:19
2453665 /home/taviso/install_special_mapping
00011000-
ffffe000 rwxp
00000000 00:00 0 [stack]
It's worth noting that Red Hat are shipping with mmap_min_addr set to
4096.
Signed-off-by: Tavis Ormandy <taviso@google.com>
Acked-by: Kees Cook <kees@ubuntu.com>
Acked-by: Robert Swiecki <swiecki@google.com>
[ Changed to not drop the error code - akpm ]
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Krishna Kumar [Wed, 9 Dec 2009 20:59:58 +0000 (20:59 +0000)]
net: release dst entry while cache-hot for GSO case too
commit
068a2de57ddf4f472e32e7af868613c574ad1d88 upstream.
Non-GSO code drops dst entry for performance reasons, but
the same is missing for GSO code. Drop dst while cache-hot
for GSO case too.
Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alexander Duyck [Tue, 23 Mar 2010 18:35:18 +0000 (18:35 +0000)]
igb: only use vlan_gro_receive if vlans are registered
commit
31b24b955c3ebbb6f3008a6374e61cf7c05a193c upstream.
This change makes it so that vlan_gro_receive is only used if vlans have been
registered to the adapter structure. Previously we were just sending all vlan
tagged frames in via this function but this results in a null pointer
dereference when vlans are not registered.
[ This fixes bugzilla entry 15582 -Eric Dumazet]
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Krishna Gudipati [Fri, 21 May 2010 21:39:45 +0000 (14:39 -0700)]
bfa: fix system crash when reading sysfs fc_host statistics
commit
7873ca4e4401f0ecd8868bf1543113467e6bae61 upstream.
The port data structure related to fc_host statistics collection is
not initialized. This causes system crash when reading the fc_host
statistics. The fix is to initialize port structure during driver
attach.
Signed-off-by: Krishna Gudipati <kgudipat@brocade.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jiri Slaby [Tue, 19 Oct 2010 09:29:55 +0000 (11:29 +0200)]
HID: hidraw: fix window in hidraw_release
commit
cb174681a9ececa6702f114b85bdf82144b6a5af upstream.
[ Backport to .32.y by Antonio Ospite <ospite@studenti.unina.it> ]
There is a window between hidraw_table check and its dereference.
In that window, the device may be unplugged and removed form the
system and we will then dereference NULL.
Lock that place properly so that either we get NULL and jump out or we
can work with real pointer.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Anton Blanchard [Tue, 6 Apr 2010 11:42:38 +0000 (21:42 +1000)]
hvc_console: Fix race between hvc_close and hvc_remove, again
commit
320718ee074acce5ffced6506cb51af1388942aa upstream.
I don't claim to understand the tty layer, but it seems like hvc_open and
hvc_close should be balanced in their kref reference counting.
Right now we get a kref every call to hvc_open:
if (hp->count++ > 0) {
tty_kref_get(tty); <----- here
spin_unlock_irqrestore(&hp->lock, flags);
hvc_kick();
return 0;
} /* else count == 0 */
tty->driver_data = hp;
hp->tty = tty_kref_get(tty); <------ or here if hp->count was 0
But hvc_close has:
tty_kref_get(tty);
if (--hp->count == 0) {
...
/* Put the ref obtained in hvc_open() */
tty_kref_put(tty);
...
}
tty_kref_put(tty);
Since the outside kref get/put balance we only do a single kref_put when
count reaches 0.
The patch below changes things to call tty_kref_put once for every
hvc_close call, and with that my machine boots fine.
Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Amit Shah [Fri, 12 Mar 2010 06:23:15 +0000 (11:53 +0530)]
hvc_console: Fix race between hvc_close and hvc_remove
commit
e74d098c66543d0731de62eb747ccd5b636a6f4c upstream.
Alan pointed out a race in the code where hvc_remove is invoked. The
recent virtio_console work is the first user of hvc_remove().
Alan describes it thus:
The hvc_console assumes that a close and remove call can't occur at the
same time.
In addition tty_hangup(tty) is problematic as tty_hangup is asynchronous
itself....
So this can happen
hvc_close hvc_remove
hung up ? - no
lock
tty = hp->tty
unlock
lock
hp->tty = NULL
unlock
notify del
kref_put the hvc struct
close completes
tty is destroyed
tty_hangup dead tty
tty->ops will be NULL
NULL->...
This patch adds some tty krefs and also converts to using tty_vhangup().
Reported-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk>
CC: linuxppc-dev@ozlabs.org
CC: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Suresh Siddha [Mon, 6 Dec 2010 20:26:30 +0000 (12:26 -0800)]
x86, vt-d: Quirk for masking vtd spec errors to platform error handling logic
commit
254e42006c893f45bca48f313536fcba12206418 upstream.
On platforms with Intel 7500 chipset, there were some reports of system
hang/NMI's during kexec/kdump in the presence of interrupt-remapping enabled.
During kdump, there is a window where the devices might be still using old
kernel's interrupt information, while the kdump kernel is coming up. This can
cause vt-d faults as the interrupt configuration from the old kernel map to
null IRTE entries in the new kernel etc. (with out interrupt-remapping enabled,
we still have the same issue but in this case we will see benign spurious
interrupt hit the new kernel).
Based on platform config settings, these platforms seem to generate NMI/SMI
when a vt-d fault happens and there were reports that the resulting SMI causes
the system to hang.
Fix it by masking vt-d spec defined errors to platform error reporting logic.
VT-d spec related errors are already handled by the VT-d OS code, so need to
report the same error through other channels.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <
1291667190.2675.8.camel@sbsiddha-MOBL3.sc.intel.com>
Reported-by: Max Asbock <masbock@linux.vnet.ibm.com>
Reported-and-tested-by: Takao Indoh <indou.takao@jp.fujitsu.com>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kenji Kaneshige [Wed, 1 Dec 2010 17:40:32 +0000 (09:40 -0800)]
x86, vt-d: Fix the vt-d fault handling irq migration in the x2apic mode
commit
086e8ced65d9bcc4a8e8f1cd39b09640f2883f90 upstream.
In x2apic mode, we need to set the upper address register of the fault
handling interrupt register of the vt-d hardware. Without this
irq migration of the vt-d fault handling interrupt is broken.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
LKML-Reference: <
1291225233.2648.39.camel@sbsiddha-MOBL3>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Tested-by: Takao Indoh <indou.takao@jp.fujitsu.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Suresh Siddha [Wed, 1 Dec 2010 06:22:29 +0000 (22:22 -0800)]
x86, vt-d: Handle previous faults after enabling fault handling
commit
7f99d946e71e71d484b7543b49e990508e70d0c0 upstream.
Fault handling is getting enabled after enabling the interrupt-remapping (as
the success of interrupt-remapping can affect the apic mode and hence the
fault handling mode).
Hence there can potentially be some faults between the window of enabling
interrupt-remapping in the vt-d and the fault-handling of the vt-d units.
Handle any previous faults after enabling the vt-d fault handling.
For v2.6.38 cleanup, need to check if we can remove the dmar_fault() in the
enable_intr_remapping() and see if we can enable fault handling along with
enabling intr-remapping.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <
20101201062244.
630417138@intel.com>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kenji Kaneshige [Wed, 1 Dec 2010 06:22:28 +0000 (22:22 -0800)]
x86: Enable the intr-remap fault handling after local APIC setup
commit
7f7fbf45c6b748074546f7f16b9488ca71de99c1 upstream.
Interrupt-remapping gets enabled very early in the boot, as it determines the
apic mode that the processor can use. And the current code enables the vt-d
fault handling before the setup_local_APIC(). And hence the APIC LDR registers
and data structure in the memory may not be initialized. So the vt-d fault
handling in logical xapic/x2apic modes were broken.
Fix this by enabling the vt-d fault handling in the end_local_APIC_setup()
A cleaner fix of enabling fault handling while enabling intr-remapping
will be addressed for v2.6.38. [ Enabling intr-remapping determines the
usage of x2apic mode and the apic mode determines the fault-handling
configuration. ]
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
LKML-Reference: <
20101201062244.
541996375@intel.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
H. Peter Anvin [Tue, 14 Dec 2010 00:01:38 +0000 (16:01 -0800)]
x86, gcc-4.6: Use gcc -m options when building vdso
commit
de2a8cf98ecdde25231d6c5e7901e2cffaf32af9 upstream.
The vdso Makefile passes linker-style -m options not to the linker but
to gcc. This happens to work with earlier gcc, but fails with gcc
4.6. Pass gcc-style -m options, instead.
Note: all currently supported versions of gcc supports -m32, so there
is no reason to conditionalize it any more.
Reported-by: H. J. Lu <hjl.tools@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
LKML-Reference: <tip-*@git.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Slava Pestov [Wed, 24 Nov 2010 23:13:16 +0000 (15:13 -0800)]
tracing: Fix panic when lseek() called on "trace" opened for writing
commit
364829b1263b44aa60383824e4c1289d83d78ca7 upstream.
The file_ops struct for the "trace" special file defined llseek as seq_lseek().
However, if the file was opened for writing only, seq_open() was not called,
and the seek would dereference a null pointer, file->private_data.
This patch introduces a new wrapper for seq_lseek() which checks if the file
descriptor is opened for reading first. If not, it does nothing.
Signed-off-by: Slava Pestov <slavapestov@google.com>
LKML-Reference: <
1290640396-24179-1-git-send-email-slavapestov@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
NeilBrown [Thu, 9 Dec 2010 05:36:28 +0000 (16:36 +1100)]
md: fix bug with re-adding of partially recovered device.
commit
1a855a0606653d2d82506281e2c686bacb4b2f45 upstream.
With v0.90 metadata, a hot-spare does not become a full member of the
array until recovery is complete. So if we re-add such a device to
the array, we know that all of it is as up-to-date as the event count
would suggest, and so it a bitmap-based recovery is possible.
However with v1.x metadata, the hot-spare immediately becomes a full
member of the array, but it record how much of the device has been
recovered. If the array is stopped and re-assembled recovery starts
from this point.
When such a device is hot-added to an array we currently lose the 'how
much is recovered' information and incorrectly included it as a full
in-sync member (after bitmap-based fixup).
This is wrong and unsafe and could corrupt data.
So be more careful about setting saved_raid_disk - which is what
guides the re-adding of devices back into an array.
The new code matches the code in slot_store which does a similar
thing, which is encouraging.
This is suitable for any -stable kernel.
Reported-by: "Dailey, Nate" <Nate.Dailey@stratus.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andreas Herrmann [Thu, 16 Dec 2010 20:29:37 +0000 (21:29 +0100)]
x86, amd: Fix panic on AMD CPU family 0x15
[The mainline kernel doesn't have this problem. Commit "(
23588c3) x86,
amd: Add support for CPUID topology extension of AMD CPUs" removed the
family check. But 2.6.32.y needs to be fixed.]
This CPU family check is not required -- existence of the NodeId MSR
is indicated by a CPUID feature flag which is already checked in
amd_fixup_dcm() -- and it needlessly prevents amd_fixup_dcm() to be
called for newer AMD CPUs.
In worst case this can lead to a panic in the scheduler code for AMD
family 0x15 multi-node AMD CPUs. I just have a picture of VGA console
output so I can't copy-and-paste it herein, but the call stack of such
a panic looked like:
do_divide_error
...
find_busiest_group
run_rebalance_domains
...
apic_timer_interrupt
...
cpu_idle
The mainline kernel doesn't have this problem. Commit "(
23588c3) x86,
amd: Add support for CPUID topology extension of AMD CPUs" removed the
family check. But 2.6.32.y needs to be fixed.
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Kilroy [Sun, 5 Dec 2010 15:45:58 +0000 (15:45 +0000)]
orinoco: clear countermeasure setting on commit
commit
ba34fcee476d11e7c9df95932787a22a96ff6e68 upstream.
... and interface up.
In these situations, you are usually trying to connect to a new AP, so
keeping TKIP countermeasures active is confusing. This is already how
the driver behaves (inadvertently). However, querying SIOCGIWAUTH may
tell userspace that countermeasures are active when they aren't.
Clear the setting so that the reporting matches what the driver has
done..
Signed-off by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Kilroy [Sun, 5 Dec 2010 15:43:55 +0000 (15:43 +0000)]
orinoco: fix TKIP countermeasure behaviour
commit
0a54917c3fc295cb61f3fb52373c173fd3b69f48 upstream.
Enable the port when disabling countermeasures, and disable it on
enabling countermeasures.
This bug causes the response of the system to certain attacks to be
ineffective.
It also prevents wpa_supplicant from getting scan results, as
wpa_supplicant disables countermeasures on startup - preventing the
hardware from scanning.
wpa_supplicant works with ap_mode=2 despite this bug because the commit
handler re-enables the port.
The log tends to look like:
State: DISCONNECTED -> SCANNING
Starting AP scan for wildcard SSID
Scan requested (ret=0) - scan timeout 5 seconds
EAPOL: disable timer tick
EAPOL: Supplicant port status: Unauthorized
Scan timeout - try to get results
Failed to get scan results
Failed to get scan results - try scanning again
Setting scan request: 1 sec 0 usec
Starting AP scan for wildcard SSID
Scan requested (ret=-1) - scan timeout 5 seconds
Failed to initiate AP scan.
Reported by: Giacomo Comes <comes@naic.edu>
Signed-off by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alexey Starikovskiy [Thu, 9 Dec 2010 22:07:54 +0000 (17:07 -0500)]
ACPI: EC: Add another dmi match entry for MSI hardware
commit
a5dc4f898c2a0f66e2cefada6c687db82ba2fcbc upstream.
http://bugzilla.kernel.org/show_bug.cgi?id=15418
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Bob Moore [Sat, 23 Oct 2010 05:36:40 +0000 (01:36 -0400)]
ACPICA: Fix Scope() op in module level code
commit
8df3fc981dc12d9fdcaef4100a2193b605024d7a upstream.
Some Panasonic Toughbooks create nodes in module level code.
Module level code is the executable AML code outside of control method,
for example, below AML code creates a node \_SB.PCI0.GFX0.DD02.CUBL
If (\_OSI ("Windows 2006"))
{
Scope (\_SB.PCI0.GFX0.DD02)
{
Name (CUBL, Ones)
...
}
}
Scope() op does not actually create a new object, it refers to an
existing object(\_SB.PCI0.GFX0.DD02 in above example). However, for
Scope(), we want to indeed open a new scope, so the child nodes(CUBL in
above example) can be created correctly under it.
https://bugzilla.kernel.org/show_bug.cgi?id=19462
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Takashi Iwai [Thu, 9 Dec 2010 23:16:39 +0000 (00:16 +0100)]
PM / Hibernate: Fix PM_POST_* notification with user-space suspend
commit
1497dd1d29c6a53fcd3c80f7ac8d0e0239e7389e upstream.
The user-space hibernation sends a wrong notification after the image
restoration because of thinko for the file flag check. RDONLY
corresponds to hibernation and WRONLY to restoration, confusingly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Carpenter [Wed, 13 Oct 2010 09:13:12 +0000 (09:13 +0000)]
IB/uverbs: Handle large number of entries in poll CQ
commit
7182afea8d1afd432a17c18162cc3fd441d0da93 upstream.
In ib_uverbs_poll_cq() code there is a potential integer overflow if
userspace passes in a large cmd.ne. The calls to kmalloc() would
allocate smaller buffers than intended, leading to memory corruption.
There iss also an information leak if resp wasn't all used.
Unprivileged userspace may call this function, although only if an
RDMA device that uses this function is present.
Fix this by copying CQ entries one at a time, which avoids the
allocation entirely, and also by moving this copying into a function
that makes sure to initialize all memory copied to userspace.
Special thanks to Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
for his help and advice.
Signed-off-by: Dan Carpenter <error27@gmail.com>
[ Monkey around with things a bit to avoid bad code generation by gcc
when designated initializers are used. - Roland ]
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Borislav Petkov [Mon, 6 Dec 2010 15:20:25 +0000 (16:20 +0100)]
amd64_edac: Fix interleaving check
commit
e726f3c368e7c1919a7166ec09c5705759f1a69d upstream.
When matching error address to the range contained by one memory node,
we're in valid range when node interleaving
1. is disabled, or
2. enabled and when the address bits we interleave on match the
interleave selector on this node (see the "Node Interleaving" section in
the BKDG for an enlightening example).
Thus, when we early-exit, we need to reverse the compound logic
statement properly.
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Gabriele Gorla [Wed, 8 Dec 2010 15:27:22 +0000 (16:27 +0100)]
hwmon: (adm1026) Fix setting fan_div
commit
52bc9802ce849d0d287cc5fe76d06b0daa3986ca upstream.
Prevent setting fan_div from stomping on other fans that share the
same I2C register.
Signed-off-by: Gabriele Gorla <gorlik@penguintown.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Gabriele Gorla [Wed, 8 Dec 2010 15:27:22 +0000 (16:27 +0100)]
hwmon: (adm1026) Allow 1 as a valid divider value
commit
8b0f1840a46449e1946fc88860ef3ec8d6b1c2c7 upstream.
Allow 1 as a valid div value as specified in the ADM1026 datasheet.
Signed-off-by: Gabriele Gorla <gorlik@penguintown.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
NeilBrown [Tue, 16 Nov 2010 05:55:19 +0000 (16:55 +1100)]
sunrpc: prevent use-after-free on clearing XPT_BUSY
commit
ed2849d3ecfa339435818eeff28f6c3424300cec upstream.
When an xprt is created, it has a refcount of 1, and XPT_BUSY is set.
The refcount is *not* owned by the thread that created the xprt
(as is clear from the fact that creators never put the reference).
Rather, it is owned by the absence of XPT_DEAD. Once XPT_DEAD is set,
(And XPT_BUSY is clear) that initial reference is dropped and the xprt
can be freed.
So when a creator clears XPT_BUSY it is dropping its only reference and
so must not touch the xprt again.
However svc_recv, after calling ->xpo_accept (and so getting an XPT_BUSY
reference on a new xprt), calls svc_xprt_recieved. This clears
XPT_BUSY and then svc_xprt_enqueue - this last without owning a reference.
This is dangerous and has been seen to leave svc_xprt_enqueue working
with an xprt containing garbage.
So we need to hold an extra counted reference over that call to
svc_xprt_received.
For safety, any time we clear XPT_BUSY and then use the xprt again, we
first get a reference, and the put it again afterwards.
Note that svc_close_all does not need this extra protection as there are
no threads running, and the final free can only be called asynchronously
from such a thread.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sergey Vlasov [Sun, 28 Nov 2010 21:04:05 +0000 (21:04 +0000)]
NFS: Fix fcntl F_GETLK not reporting some conflicts
commit
21ac19d484a8ffb66f64487846c8d53afef04d2b upstream.
The commit
129a84de2347002f09721cda3155ccfd19fade40 (locks: fix F_GETLK
regression (failure to find conflicts)) fixed the posix_test_lock()
function by itself, however, its usage in NFS changed by the commit
9d6a8c5c213e34c475e72b245a8eb709258e968c (locks: give posix_test_lock
same interface as ->lock) remained broken - subsequent NFS-specific
locking code received F_UNLCK instead of the user-specified lock type.
To fix the problem, fl->fl_type needs to be saved before the
posix_test_lock() call and restored if no local conflicts were reported.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=23892
Tested-by: Alexander Morozov <amorozov@etersoft.ru>
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Neil Brown [Thu, 2 Dec 2010 00:14:30 +0000 (11:14 +1100)]
nfsd: Fix possible BUG_ON firing in set_change_info
commit
c1ac3ffcd0bc7e9617f62be8c7043d53ab84deac upstream.
If vfs_getattr in fill_post_wcc returns an error, we don't
set fh_post_change.
For NFSv4, this can result in set_change_info triggering a BUG_ON.
i.e. fh_post_saved being zero isn't really a bug.
So:
- instead of BUGging when fh_post_saved is zero, just clear ->atomic.
- if vfs_getattr fails in fill_post_wcc, take a copy of i_ctime anyway.
This will be used i seg_change_info, but not overly trusted.
- While we are there, remove the pointless 'if' statements in set_change_info.
There is no harm setting all the values.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Chuck Lever [Fri, 10 Dec 2010 17:31:14 +0000 (12:31 -0500)]
NFS: Fix panic after nfs_umount()
commit
5b362ac3799ff4225c40935500f520cad4d7ed66 upstream.
After a few unsuccessful NFS mount attempts in which the client and
server cannot agree on an authentication flavor both support, the
client panics. nfs_umount() is invoked in the kernel in this case.
Turns out nfs_umount()'s UMNT RPC invocation causes the RPC client to
write off the end of the rpc_clnt's iostat array. This is because the
mount client's nrprocs field is initialized with the count of defined
procedures (two: MNT and UMNT), rather than the size of the client's
proc array (four).
The fix is to use the same initialization technique used by most other
upper layer clients in the kernel.
Introduced by commit
0b524123, which failed to update nrprocs when
support was added for UMNT in the kernel.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=24302
BugLink: http://bugs.launchpad.net/bugs/683938
Reported-by: Stefan Bader <stefan.bader@canonical.com>
Tested-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Heiko Carstens [Wed, 1 Dec 2010 09:11:09 +0000 (10:11 +0100)]
nohz: Fix get_next_timer_interrupt() vs cpu hotplug
commit
dbd87b5af055a0cc9bba17795c9a2b0d17795389 upstream.
This fixes a bug as seen on 2.6.32 based kernels where timers got
enqueued on offline cpus.
If a cpu goes offline it might still have pending timers. These will
be migrated during CPU_DEAD handling after the cpu is offline.
However while the cpu is going offline it will schedule the idle task
which will then call tick_nohz_stop_sched_tick().
That function in turn will call get_next_timer_intterupt() to figure
out if the tick of the cpu can be stopped or not. If it turns out that
the next tick is just one jiffy off (delta_jiffies == 1)
tick_nohz_stop_sched_tick() incorrectly assumes that the tick should
not stop and takes an early exit and thus it won't update the load
balancer cpu.
Just afterwards the cpu will be killed and the load balancer cpu could
be the offline cpu.
On 2.6.32 based kernel get_nohz_load_balancer() gets called to decide
on which cpu a timer should be enqueued (see __mod_timer()). Which
leads to the possibility that timers get enqueued on an offline cpu.
These will never expire and can cause a system hang.
This has been observed 2.6.32 kernels. On current kernels
__mod_timer() uses get_nohz_timer_target() which doesn't have that
problem. However there might be other problems because of the too
early exit tick_nohz_stop_sched_tick() in case a cpu goes offline.
The easiest and probably safest fix seems to be to let
get_next_timer_interrupt() just lie and let it say there isn't any
pending timer if the current cpu is offline.
I also thought of moving migrate_[hr]timers() from CPU_DEAD to
CPU_DYING, but seeing that there already have been fixes at least in
the hrtimer code in this area I'm afraid that this could add new
subtle bugs.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <
20101201091109.GA8984@osiris.boeblingen.de.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Heiko Carstens [Fri, 26 Nov 2010 12:00:59 +0000 (13:00 +0100)]
nohz: Fix printk_needs_cpu() return value on offline cpus
commit
61ab25447ad6334a74e32f60efb135a3467223f8 upstream.
This patch fixes a hang observed with 2.6.32 kernels where timers got enqueued
on offline cpus.
printk_needs_cpu() may return 1 if called on offline cpus. When a cpu gets
offlined it schedules the idle process which, before killing its own cpu, will
call tick_nohz_stop_sched_tick(). That function in turn will call
printk_needs_cpu() in order to check if the local tick can be disabled. On
offline cpus this function should naturally return 0 since regardless if the
tick gets disabled or not the cpu will be dead short after. That is besides the
fact that __cpu_disable() should already have made sure that no interrupts on
the offlined cpu will be delivered anyway.
In this case it prevents tick_nohz_stop_sched_tick() to call
select_nohz_load_balancer(). No idea if that really is a problem. However what
made me debug this is that on 2.6.32 the function get_nohz_load_balancer() is
used within __mod_timer() to select a cpu on which a timer gets enqueued. If
printk_needs_cpu() returns 1 then the nohz_load_balancer cpu doesn't get
updated when a cpu gets offlined. It may contain the cpu number of an offline
cpu. In turn timers get enqueued on an offline cpu and not very surprisingly
they never expire and cause system hangs.
This has been observed 2.6.32 kernels. On current kernels __mod_timer() uses
get_nohz_timer_target() which doesn't have that problem. However there might be
other problems because of the too early exit tick_nohz_stop_sched_tick() in
case a cpu goes offline.
Easiest way to fix this is just to test if the current cpu is offline and call
printk_tick() directly which clears the condition.
Alternatively I tried a cpu hotplug notifier which would clear the condition,
however between calling the notifier function and printk_needs_cpu() something
could have called printk() again and the problem is back again. This seems to
be the safest fix.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <
20101126120235.
406766476@de.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alex Deucher [Thu, 9 Dec 2010 00:09:42 +0000 (19:09 -0500)]
drm/kms: remove spaces from connector names (v2)
commit
e76116ca9671e2e5239054a40303b94feab585ad upstream.
Grub doesn't parse spaces in parameters correctly, so
this makes it impossible to force video= parameters
for kms on the grub kernel command line.
v2: shorten the names to make them easier to type.
Reported-by: Sergej Pupykin <ml@sergej.pp.ru>
Cc: Sergej Pupykin <ml@sergej.pp.ru>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel T Chen [Fri, 3 Dec 2010 03:45:45 +0000 (22:45 -0500)]
ALSA: hda: Use model=lg quirk for LG P1 Express to enable playback and capture
commit
77c4d5cdb81d25a45fbdfb84dd3348121219a072 upstream.
BugLink: https://launchpad.net/bugs/595482
The original reporter states that audible playback from the internal
speaker is inaudible despite the hardware being properly detected. To
work around this symptom, he uses the model=lg quirk to properly enable
both playback, capture, and jack sense. Another user corroborates this
workaround on separate hardware. Add this PCI SSID to the quirk table
to enable it for further LG P1 Expresses.
Reported-and-tested-by: Philip Peitsch <philip.peitsch@gmail.com>
Tested-by: nikhov
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Miklos Szeredi [Tue, 30 Nov 2010 15:39:27 +0000 (16:39 +0100)]
fuse: fix ioctl when server is 32bit
commit
d9d318d39dd5cb686660504a3565aac453709ccc upstream.
If a 32bit CUSE server is run on 64bit this results in EIO being
returned to the caller.
The reason is that FUSE_IOCTL_RETRY reply was defined to use 'struct
iovec', which is different on 32bit and 64bit archs.
Work around this by looking at the size of the reply to determine
which struct was used. This is only needed if CONFIG_COMPAT is
defined.
A more permanent fix for the interface will be to use the same struct
on both 32bit and 64bit.
Reported-by: "ccmail111" <ccmail111@yahoo.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
CC: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Miklos Szeredi [Tue, 30 Nov 2010 15:39:27 +0000 (16:39 +0100)]
fuse: verify ioctl retries
commit
7572777eef78ebdee1ecb7c258c0ef94d35bad16 upstream.
Verify that the total length of the iovec returned in FUSE_IOCTL_RETRY
doesn't overflow iov_length().
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
CC: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
H. Peter Anvin [Sat, 11 Dec 2010 04:57:04 +0000 (23:57 -0500)]
x86, hotplug: Use mwait to offline a processor, fix the legacy case
upstream
ea53069231f9317062910d6e772cca4ce93de8c8
x86, hotplug: Use mwait to offline a processor, fix the legacy case
Here included also some small follow-on patches to the same code:
upstream
a68e5c94f7d3dd64fef34dd5d97e365cae4bb42a
x86, hotplug: Move WBINVD back outside the play_dead loop
upstream
ce5f68246bf2385d6174856708d0b746dc378f20
x86, hotplug: In the MWAIT case of play_dead, CLFLUSH the cache line
https://bugzilla.kernel.org/show_bug.cgi?id=5471
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Sat, 11 Dec 2010 05:51:39 +0000 (05:51 +0000)]
TTY: Fix error return from tty_ldisc_open()
The backported version of "TTY: ldisc, fix open flag handling" in
2.6.32.27 causes tty_ldisc_open() to return 0 on error. Fix that.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Thu, 9 Dec 2010 21:29:45 +0000 (13:29 -0800)]
Linux 2.6.32.27
Robin Holt [Wed, 16 Dec 2009 00:47:57 +0000 (16:47 -0800)]
x86: uv: xpc NULL deref when mesq becomes empty
commit
15b87d67ff3dc042bee42f991858d6b121b3b3ca upstream.
Under heavy load conditions, our set of xpc messages may become exhausted.
The code handles this correctly with the exception of the management code
which hits a NULL pointer dereference.
Signed-off-by: Robin Holt <holt@sgi.com>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Robin Holt [Wed, 16 Dec 2009 00:47:58 +0000 (16:47 -0800)]
X86: uv: xpc_make_first_contact hang due to not accepting ACTIVE state
commit
dbd2918ec65c35f36bb102c88eafe87be0552f6f upstream.
Many times while the initial connection is being made, the contacted
partition will send back both the ACTIVATING and the ACTIVE
remote_act_state changes in very close succescion. The 1/4 second delay
in the make first contact loop is large enough to nearly always miss the
ACTIVATING state change.
Since either state indicates the remote partition has acknowledged our
state change, accept either.
Signed-off-by: Robin Holt <holt@sgi.com>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Robin Holt [Wed, 16 Dec 2009 00:47:59 +0000 (16:47 -0800)]
x86: uv: XPC receive message reuse triggers invalid BUG_ON()
commit
046d6c563b1c6226bbf0f84e5b2413ad8ab921a1 upstream.
This was a difficult bug to trip. XPC was in the middle of sending an
acknowledgement for a received message.
In xpc_received_payload_uv():
.
ret = xpc_send_gru_msg(ch->sn.uv.cached_notify_gru_mq_desc, msg,
sizeof(struct xpc_notify_mq_msghdr_uv));
if (ret != xpSuccess)
XPC_DEACTIVATE_PARTITION(&xpc_partitions[ch->partid], ret);
msg->hdr.msg_slot_number += ch->remote_nentries;
at the point in xpc_send_gru_msg() where the hardware has dispatched the
acknowledgement, the remote side is able to reuse the message structure
and send a message with a different slot number. This problem is made
worse by interrupts.
The adjustment of msg_slot_number and the BUG_ON in
xpc_handle_notify_mq_msg_uv() which verifies the msg_slot_number is
consistent are only used for debug purposes. Since a fix for this that
preserves the debug functionality would either have to infringe upon the
payload or allocate another structure just for debug, I decided to remove
it entirely.
Signed-off-by: Robin Holt <holt@sgi.com>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Robin Holt [Wed, 16 Dec 2009 00:48:00 +0000 (16:48 -0800)]
UV - XPC: pass nasid instead of nid to gru_create_message_queue
commit
57e6d258b1e41cd7ceb26fa43ce116939d8440b1 upstream.
Currently, the UV xpc code is passing nid to the gru_create_message_queue
instead of nasid as it expects.
Signed-off-by: Robin Holt <holt@sgi.com>
Signed-off-by: Jack Steiner <steiner@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Dumazet [Mon, 16 Aug 2010 20:04:22 +0000 (20:04 +0000)]
net sched: fix some kernel memory leaks
commit
1c40be12f7d8ca1d387510d39787b12e512a7ce8 upstream.
We leak at least 32bits of kernel memory to user land in tc dump,
because we dont init all fields (capab ?) of the dumped structure.
Use C99 initializers so that holes and non explicit fields are zeroed.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: dann frazier <dannf@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Changli Gao [Tue, 29 Jun 2010 23:07:09 +0000 (23:07 +0000)]
act_nat: use stack variable
commit
504f85c9d05f7c605306e808f0d835fe11bfd18d upstream.
act_nat: use stack variable
structure tc_nat isn't too big for stack, so we can put it in stack.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Cc: dann frazier <dannf@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Heiko Carstens [Thu, 25 Nov 2010 08:52:45 +0000 (09:52 +0100)]
nmi: fix clock comparator revalidation
commit
e8129c642155616d9e2160a75f103e127c8c3708 upstream.
On each machine check all registers are revalidated. The save area for
the clock comparator however only contains the upper most seven bytes
of the former contents, if valid.
Therefore the machine check handler uses a store clock instruction to
get the current time and writes that to the clock comparator register
which in turn will generate an immediate timer interrupt.
However within the lowcore the expected time of the next timer
interrupt is stored. If the interrupt happens before that time the
handler won't be called. In turn the clock comparator won't be
reprogrammed and therefore the interrupt condition stays pending which
causes an interrupt loop until the expected time is reached.
On NOHZ machines this can result in unresponsive machines since the
time of the next expected interrupted can be a couple of days in the
future.
To fix this just revalidate the clock comparator register with the
expected value.
In addition the special handling for udelay must be changed as well.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Thu, 28 Oct 2010 18:41:55 +0000 (11:41 -0700)]
net: Limit socket I/O iovec total length to INT_MAX.
commit
8acfe468b0384e834a303f08ebc4953d72fb690a upstream.
This helps protect us from overflow issues down in the
individual protocol sendmsg/recvmsg handlers. Once
we hit INT_MAX we truncate out the rest of the iovec
by setting the iov_len members to zero.
This works because:
1) For SOCK_STREAM and SOCK_SEQPACKET sockets, partial
writes are allowed and the application will just continue
with another write to send the rest of the data.
2) For datagram oriented sockets, where there must be a
one-to-one correspondance between write() calls and
packets on the wire, INT_MAX is going to be far larger
than the packet size limit the protocol is going to
check for and signal with -EMSGSIZE.
Based upon a patch by Linus Torvalds.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linus Torvalds [Sat, 30 Oct 2010 23:43:10 +0000 (16:43 -0700)]
net: Truncate recvfrom and sendto length to INT_MAX.
commit
253eacc070b114c2ec1f81b067d2fed7305467b0 upstream.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Wed, 17 Nov 2010 06:37:16 +0000 (06:37 +0000)]
rds: Integer overflow in RDS cmsg handling
commit
218854af84038d828a32f061858b1902ed2beec6 upstream.
In rds_cmsg_rdma_args(), the user-provided args->nr_local value is
restricted to less than UINT_MAX. This seems to need a tighter upper
bound, since the calculation of total iov_size can overflow, resulting
in a small sock_kmalloc() allocation. This would probably just result
in walking off the heap and crashing when calling rds_rdma_pages() with
a high count value. If it somehow doesn't crash here, then memory
corruption could occur soon after.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Phil Blundell [Wed, 24 Nov 2010 19:49:53 +0000 (11:49 -0800)]
econet: fix CVE-2010-3850
commit
16c41745c7b92a243d0874f534c1655196c64b74 upstream.
Add missing check for capable(CAP_NET_ADMIN) in SIOCSIFADDR operation.
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Phil Blundell [Wed, 24 Nov 2010 19:49:19 +0000 (11:49 -0800)]
econet: disallow NULL remote addr for sendmsg(), fixes CVE-2010-3849
commit
fa0e846494792e722d817b9d3d625a4ef4896c96 upstream.
Later parts of econet_sendmsg() rely on saddr != NULL, so return early
with EINVAL if NULL was passed otherwise an oops may occur.
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
H. Peter Anvin [Wed, 18 Aug 2010 18:42:23 +0000 (11:42 -0700)]
x86-32: Fix dummy trampoline-related inline stubs
commit
8848a91068c018bc91f597038a0f41462a0f88a4 upstream.
Fix dummy inline stubs for trampoline-related functions when no
trampolines exist (until we get rid of the no-trampoline case
entirely.)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Cc: Borislav Petkov <borislav.petkov@amd.com>
LKML-Reference: <
4C6C294D.
3030404@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Hugh Dickins [Wed, 25 Aug 2010 05:44:12 +0000 (22:44 -0700)]
x86, mm: Fix CONFIG_VMSPLIT_1G and 2G_OPT trampoline
commit
b7d460897739e02f186425b7276e3fdb1595cea7 upstream.
rc2 kernel crashes when booting second cpu on this CONFIG_VMSPLIT_2G_OPT
laptop: whereas cloning from kernel to low mappings pgd range does need
to limit by both KERNEL_PGD_PTRS and KERNEL_PGD_BOUNDARY, cloning kernel
pgd range itself must not be limited by the smaller KERNEL_PGD_BOUNDARY.
Signed-off-by: Hugh Dickins <hughd@google.com>
LKML-Reference: <alpine.LSU.2.00.
1008242235120.2515@sister.anvils>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Joerg Roedel [Mon, 16 Aug 2010 12:38:33 +0000 (14:38 +0200)]
x86-32: Separate 1:1 pagetables from swapper_pg_dir
commit
fd89a137924e0710078c3ae855e7cec1c43cb845 upstream.
This patch fixes machine crashes which occur when heavily exercising the
CPU hotplug codepaths on a 32-bit kernel. These crashes are caused by
AMD Erratum 383 and result in a fatal machine check exception. Here's
the scenario:
1. On 32-bit, the swapper_pg_dir page table is used as the initial page
table for booting a secondary CPU.
2. To make this work, swapper_pg_dir needs a direct mapping of physical
memory in it (the low mappings). By adding those low, large page (2M)
mappings (PAE kernel), we create the necessary conditions for Erratum
383 to occur.
3. Other CPUs which do not participate in the off- and onlining game may
use swapper_pg_dir while the low mappings are present (when leave_mm is
called). For all steps below, the CPU referred to is a CPU that is using
swapper_pg_dir, and not the CPU which is being onlined.
4. The presence of the low mappings in swapper_pg_dir can result
in TLB entries for addresses below __PAGE_OFFSET to be established
speculatively. These TLB entries are marked global and large.
5. When the CPU with such TLB entry switches to another page table, this
TLB entry remains because it is global.
6. The process then generates an access to an address covered by the
above TLB entry but there is a permission mismatch - the TLB entry
covers a large global page not accessible to userspace.
7. Due to this permission mismatch a new 4kb, user TLB entry gets
established. Further, Erratum 383 provides for a small window of time
where both TLB entries are present. This results in an uncorrectable
machine check exception signalling a TLB multimatch which panics the
machine.
There are two ways to fix this issue:
1. Always do a global TLB flush when a new cr3 is loaded and the
old page table was swapper_pg_dir. I consider this a hack hard
to understand and with performance implications
2. Do not use swapper_pg_dir to boot secondary CPUs like 64-bit
does.
This patch implements solution 2. It introduces a trampoline_pg_dir
which has the same layout as swapper_pg_dir with low_mappings. This page
table is used as the initial page table of the booting CPU. Later in the
bringup process, it switches to swapper_pg_dir and does a global TLB
flush. This fixes the crashes in our test cases.
-v2: switch to swapper_pg_dir right after entering start_secondary() so
that we are able to access percpu data which might not be mapped in the
trampoline page table.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
LKML-Reference: <
20100816123833.GB28147@aftab>
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Herbert Xu [Thu, 4 Nov 2010 18:38:39 +0000 (14:38 -0400)]
crypto: padlock - Fix AES-CBC handling on odd-block-sized input
commit
c054a076a1bd4731820a9c4d638b13d5c9bf5935 upstream.
On certain VIA chipsets AES-CBC requires the input/output to be
a multiple of 64 bytes. We had a workaround for this but it was
buggy as it sent the whole input for processing when it is meant
to only send the initial number of blocks which makes the rest
a multiple of 64 bytes.
As expected this causes memory corruption whenever the workaround
kicks in.
Reported-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Fri, 12 Nov 2010 20:44:42 +0000 (12:44 -0800)]
x25: Prevent crashing when parsing bad X.25 facilities
commit
5ef41308f94dcbb3b7afc56cdef1c2ba53fa5d2f upstream.
Now with improved comma support.
On parsing malformed X.25 facilities, decrementing the remaining length
may cause it to underflow. Since the length is an unsigned integer,
this will result in the loop continuing until the kernel crashes.
This patch adds checks to ensure decrementing the remaining length does
not cause it to wrap around.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Wed, 15 Sep 2010 21:44:22 +0000 (18:44 -0300)]
V4L/DVB: ivtvfb: prevent reading uninitialized stack memory
commit
405707985594169cfd0b1d97d29fcb4b4c6f2ac9 upstream.
The FBIOGET_VBLANK device ioctl allows unprivileged users to read 16
bytes of uninitialized stack memory, because the "reserved" member of
the fb_vblank struct declared on the stack is not altered or zeroed
before being copied back to the user. This patch takes care of it.
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Oliver Hartkopp [Wed, 10 Nov 2010 12:10:30 +0000 (12:10 +0000)]
can-bcm: fix minor heap overflow
commit
0597d1b99fcfc2c0eada09a698f85ed413d4ba84 upstream.
On 64-bit platforms the ASCII representation of a pointer may be up to 17
bytes long. This patch increases the length of the buffer accordingly.
http://marc.info/?l=linux-netdev&m=
128872251418192&w=2
Reported-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
CC: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
andrew hendry [Wed, 3 Nov 2010 12:54:53 +0000 (12:54 +0000)]
memory corruption in X.25 facilities parsing
commit
a6331d6f9a4298173b413cf99a40cc86a9d92c37 upstream.
Signed-of-by: Andrew Hendry <andrew.hendry@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
John Hughes [Thu, 8 Apr 2010 04:29:25 +0000 (21:29 -0700)]
x25: Patch to fix bug 15678 - x25 accesses fields beyond end of packet.
commit
f5eb917b861828da18dc28854308068c66d1449a upstream.
Here is a patch to stop X.25 examining fields beyond the end of the packet.
For example, when a simple CALL ACCEPTED was received:
10 10 0f
x25_parse_facilities was attempting to decode the FACILITIES field, but this
packet contains no facilities field.
Signed-off-by: John Hughes <john@calva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Torokhov [Thu, 4 Nov 2010 16:12:44 +0000 (09:12 -0700)]
Input: i8042 - add Sony VAIO VPCZ122GX to nomux list
[Note that the mainline will not have this particular fix but rather
will blacklist entire VAIO line based off DMI board name. For stable
I am being a bit more cautious and blacklist one particular product.]
Trying to query/activate active multiplexing mode on this VAIO makes
both keyboard and touchpad inoperable. Futher kernels will blacklist
entire VAIO line, however here we blacklist just one particular model.
Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Laurent Pinchart [Thu, 8 Oct 2009 22:38:10 +0000 (19:38 -0300)]
V4L/DVB (13154): uvcvideo: Handle garbage at the end of streaming interface descriptors
commit
c4ed8c66d79d707d89fe732ff5b97739edf1ba62 upstream.
At least one 5986:0241 webcam model includes vendor-specific descriptors
at the end of its streaming interface descriptors. Print an information
UVC_TRACE_DESCR message and try to continue parsing the descriptors
rather than bailing out with an error.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: maximilian attems <max@stro.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Luke Macken [Wed, 22 Sep 2010 20:05:04 +0000 (13:05 -0700)]
efifb: support the EFI framebuffer on more Apple hardware
commit
a5757c2a474a15f87e5baa9a4caacc31cde2bae6 upstream.
Enable the EFI framebuffer on 14 more Macs, including the iMac11,1
iMac10,1 iMac8,1 Macmini3,1 Macmini4,1 MacBook5,1 MacBook6,1 MacBook7,1
MacBookPro2,2 MacBookPro5,2 MacBookPro5,3 MacBookPro6,1 MacBookPro6,2 and
MacBookPro7,1
Information gathered from various user submissions.
https://bugzilla.redhat.com/show_bug.cgi?id=528232
http://ubuntuforums.org/showthread.php?t=
1557326
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Luke Macken <lmacken@redhat.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: maximilian attems <max@stro.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Gerlach [Fri, 23 Apr 2010 17:17:50 +0000 (13:17 -0400)]
drivers/video/efifb.c: support framebuffer for NVIDIA 9400M in MacBook Pro 5,1
commit
8a3bdfe6cd841880a5d849c40f90093b3817f6e0 upstream.
Description of patch:
---------------------
This is a patch for the EFI framebuffer driver to enable the framebuffer
of the NVIDIA 9400M as found in MacBook Pro (MBP) 5,1 and up. The
framebuffer of the NVIDIA graphic cards are located at the following
addresses in memory:
9400M: 0xC0010000
9600M GT: 0xB0030000
The patch delivered right here only provides the memory location of the
framebuffer of the 9400M device. The 9600M GT is not covered. It is
assumed that the 9400M is used when powered up the MBP.
The information which device is currently powered and in use is stored in
the 64 bytes large EFI variable "gpu-power-prefs". More specifically,
byte 0x3B indicates whether 9600M GT (0x00) or 9400M (0x01) is online.
The PCI bus IDs are the following:
9400M: PCI 03:00:00
9600M GT: PCI 02:00:00
The EFI variables can be easily read-out and manipulated with "rEFIt", an
MBP specific bootloader tool. For more information on how handle rEFIt
and EFI variables please consult "http://refit.sourceforge.net" and
"http://ubuntuforums.org/archive/index.php/t-
1076879.html".
IMPORTANT NOTE: The information on how to activate the 9400M device given
at "ubuntuforums.org" is not correct, since it states
gpu-power-prefs[0x3B] = 0x00 -> 9400M (PCI 02:00:00)
gpu-power-prefs[0x3B] = 0x01 -> 9600M GT (PCI 03:00:00)
Actually, the assignment of the values and the PCI bus IDs are swapped.
Suggestions:
------------
To cover framebuffers of both 9400M and 9600M GT, I would suggest to
implement a conditional on "gpu-power-prefs". Depending on the value of
byte 0x3B, the according framebuffer is selected. However, this requires
kernel access to the EFI variables.
[akpm@linux-foundation.org: rename optname, per Peter Jones]
Signed-off-by: Thomas Gerlach <t.m.gerlach@freenet.de>
Acked-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: maximilian attems <max@stro.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jack Steiner [Fri, 10 Sep 2010 15:08:08 +0000 (10:08 -0500)]
x86, UV: Fix initialization of max_pnode
commit
36ac4b987bea9a95217e1af552252f275ca7fc44 upstream.
Fix calculation of "max_pnode" for systems where the the highest
blade has neither cpus or memory. (And, yes, although rare this
does occur).
Signed-off-by: Jack Steiner <steiner@sgi.com>
LKML-Reference: <
20100910150808.GA19802@sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: maximilian attems <max@stro.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jack Steiner [Wed, 17 Mar 2010 15:40:38 +0000 (10:40 -0500)]
x86, UV: Delete unneeded boot messages
commit
2acebe9ecb2b77876e87a1480729cfb2db4570dd upstream.
SGI:UV: Delete extra boot messages that describe the system
topology. These messages are no longer useful.
Signed-off-by: Jack Steiner <steiner@sgi.com>
LKML-Reference: <
20100317154038.GA29346@sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: maximilian attems <max@stro.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Wed, 22 Sep 2010 05:30:13 +0000 (22:30 -0700)]
sparc: Prevent no-handler signal syscall restart recursion.
[ Upstream commit
c27852597829128a9c9d96d79ec454a83c6b0da5 ]
Explicitly clear the "in-syscall" bit when we have no signal
handler and back up the program counters to back up the system
call.
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Wed, 22 Sep 2010 04:41:12 +0000 (21:41 -0700)]
sparc: Don't mask signal when we can't setup signal frame.
[ Upstream commit
392c21802ee3aa85cee0e703105f797a8a7b9416 ]
Don't invoke the signal handler tracehook in that situation
either.
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Tue, 21 Sep 2010 06:24:52 +0000 (23:24 -0700)]
sparc64: Fix race in signal instruction flushing.
[ Upstream commit
05c5e7698bdc54b3079a3517d86077f49ebcc788 ]
If another cpu does a very wide munmap() on the signal frame area,
it can tear down the page table hierarchy from underneath us.
Borrow an idea from the 64-bit fault path's get_user_insn(), and
disable cross call interrupts during the page table traversal
to lock them in place while we operate.
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Robin Holt [Wed, 20 Oct 2010 02:03:37 +0000 (02:03 +0000)]
Limit sysctl_tcp_mem and sysctl_udp_mem initializers to prevent integer overflows.
[ Upstream fixed this in a different way as parts of the commits:
8d987e5c7510 (net: avoid limits overflow)
a9febbb4bd13 (sysctl: min/max bounds are optional)
27b3d80a7b6a (sysctl: fix min/max handling in __do_proc_doulongvec_minmax())
-DaveM ]
On a 16TB x86_64 machine, sysctl_tcp_mem[2], sysctl_udp_mem[2], and
sysctl_sctp_mem[2] can integer overflow. Set limit such that they are
maximized without overflowing.
Signed-off-by: Robin Holt <holt@sgi.com>
To: "David S. Miller" <davem@davemloft.net>
Cc: Willy Tarreau <w@1wt.eu>
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-sctp@vger.kernel.org
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: "Pekka Savola (ipv6)" <pekkas@netcore.fi>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Vlad Yasevich <vladislav.yasevich@hp.com>
Cc: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jarek Poplawski [Tue, 19 Oct 2010 00:06:36 +0000 (00:06 +0000)]
gianfar: Fix crashes on RX path (Was Re: [Bugme-new] [Bug 19692] New: linux-2.6.36-rc5 crash with gianfar ethernet at full line rate traffic)
[ Upstream commit
0d1fe1111c667e9c713d7efc7ae468a605f236a4 ]
The rx_recycle queue is global per device but can be accesed by many
napi handlers at the same time, so it needs full skb_queue primitives
(with locking). Otherwise, various crashes caused by broken skbs are
possible.
This patch resolves, at least partly, bugzilla bug 19692. (Because of
some doubts that there could be still something around which is hard
to reproduce my proposal is to leave this bug opened for a month.)
Fixes commit:
0fd56bb5be6455d0d42241e65aed057244665e5e ("gianfar: Add
support for skb recycling")
Reported-by: emin ak <eminak71@gmail.com>
Tested-by: emin ak <eminak71@gmail.com>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
CC: Andy Fleming <afleming@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Antonio Ospite [Tue, 5 Oct 2010 15:20:17 +0000 (17:20 +0200)]
HID: hidraw, fix a NULL pointer dereference in hidraw_write
commit
e42dee9a99a3ecd32b5c027e8f7411fb5bc11eb6 upstream.
BUG: unable to handle kernel NULL pointer dereference at
0000000000000028
IP: [<
ffffffffa0f0a625>] hidraw_write+0x3b/0x116 [hid]
[...]
This is reproducible by disconnecting the device while userspace writes
to dev node in a loop and doesn't check return values in order to exit
the loop.
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Antonio Ospite [Tue, 5 Oct 2010 15:20:16 +0000 (17:20 +0200)]
HID: hidraw, fix a NULL pointer dereference in hidraw_ioctl
commit
d20d5ffab92f00188f360c44c791a5ffb988247c upstream.
BUG: unable to handle kernel NULL pointer dereference at
0000000000000028
IP: [<
ffffffffa02c66b4>] hidraw_ioctl+0xfc/0x32c [hid]
[...]
This is reproducible by disconnecting the device while userspace does
ioctl in a loop and doesn't check return values in order to exit the
loop.
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jeff Mahoney [Tue, 31 Aug 2010 13:21:42 +0000 (13:21 +0000)]
net sched: fix kernel leak in act_police
commit
0f04cfd098fb81fded74e78ea1a1b86cc6c6c31e upstream.
While reviewing commit
1c40be12f7d8ca1d387510d39787b12e512a7ce8, I
audited other users of tc_action_ops->dump for information leaks.
That commit covered almost all of them but act_police still had a leak.
opt.limit and opt.capab aren't zeroed out before the structure is
passed out.
This patch uses the C99 initializers to zero everything unused out.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Acked-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Larry Finger [Sat, 13 Nov 2010 19:01:56 +0000 (13:01 -0600)]
staging: rtl8187se: Change panic to warn when RF switch turned off
commit
f36d83a8cb7224f45fdfa1129a616dff56479a09 upstream.
This driver issues a kernel panic over conditions that do not
justify such drastic action. Change these to log entries with
a stack dump.
This patch fixes the system crash reported in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674285.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-and-Tested-by: Robie Basik <rb-oss-3@justgohome.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Tue, 16 Nov 2010 19:18:33 +0000 (11:18 -0800)]
Staging: frontier: fix up some sysfs attribute permissions
commit
3bad28ec006ad6ab2bca4e5103860b75391e3c9d and
2a767fda5d0d8dcff465724dfad6ee131489b3f2 upstream merged together.
They should not be writable by any user
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Taht <d@teklibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
James Jones [Tue, 23 Nov 2010 23:21:37 +0000 (00:21 +0100)]
ARM: 6482/2: Fix find_next_zero_bit and related assembly
commit
0e91ec0c06d2cd15071a6021c94840a50e6671aa upstream.
The find_next_bit, find_first_bit, find_next_zero_bit
and find_first_zero_bit functions were not properly
clamping to the maxbit argument at the bit level. They
were instead only checking maxbit at the byte level.
To fix this, add a compare and a conditional move
instruction to the end of the common bit-within-the-
byte code used by all the functions and be sure not to
clobber the maxbit argument before it is used.
Reviewed-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: James Jones <jajones@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Will Deacon [Fri, 19 Nov 2010 12:18:31 +0000 (13:18 +0100)]
ARM: 6489/1: thumb2: fix incorrect optimisation in usracc
commit
1142b71d85894dcff1466dd6c871ea3c89e0352c upstream.
Commit
8b592783 added a Thumb-2 variant of usracc which, when it is
called with \rept=2, calls usraccoff once with an offset of 0 and
secondly with a hard-coded offset of 4 in order to avoid incrementing
the pointer again. If \inc != 4 then we will store the data to the wrong
offset from \ptr. Luckily, the only caller that passes \rept=2 to this
function is __clear_user so we haven't been actively corrupting user data.
This patch fixes usracc to pass \inc instead of #4 to usraccoff
when it is called a second time.
Reported-by: Tony Thompson <tony.thompson@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Pekka Enberg [Mon, 8 Nov 2010 19:29:07 +0000 (21:29 +0200)]
perf_events: Fix perf_counter_mmap() hook in mprotect()
commit
63bfd7384b119409685a17d5c58f0b56e5dc03da upstream.
As pointed out by Linus, commit
dab5855 ("perf_counter: Add mmap event hooks to
mprotect()") is fundamentally wrong as mprotect_fixup() can free 'vma' due to
merging. Fix the problem by moving perf_event_mmap() hook to
mprotect_fixup().
Note: there's another successful return path from mprotect_fixup() if old
flags equal to new flags. We don't, however, need to call
perf_event_mmap() there because 'perf' already knows the VMA is
executable.
Reported-by: Dave Jones <davej@redhat.com>
Analyzed-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
Reviewed-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Tue, 23 Nov 2010 11:02:13 +0000 (11:02 +0000)]
DECnet: don't leak uninitialized stack byte
commit
3c6f27bf33052ea6ba9d82369fb460726fb779c0 upstream.
A single uninitialized padding byte is leaked to userspace.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Steven J. Magnani [Wed, 24 Nov 2010 20:56:54 +0000 (12:56 -0800)]
nommu: yield CPU while disposing VM
commit
04c3496152394d17e3bc2316f9731ee3e8a026bc upstream.
Depending on processor speed, page size, and the amount of memory a
process is allowed to amass, cleanup of a large VM may freeze the system
for many seconds. This can result in a watchdog timeout.
Make sure other tasks receive some service when cleaning up large VMs.
Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
Cc: Greg Ungerer <gerg@snapgear.com>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Uwe Kleine-König [Wed, 24 Nov 2010 20:57:14 +0000 (12:57 -0800)]
backlight: grab ops_lock before testing bd->ops
commit
d1d73578e053b981c3611e5a211534290d24a5eb upstream.
According to the comment describing ops_lock in the definition of struct
backlight_device and when comparing with other functions in backlight.c
the mutex must be hold when checking ops to be non-NULL.
Fixes a problem added by
c835ee7f4154992e6 ("backlight: Add suspend/resume
support to the backlight core") in Jan 2009.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Richard Purdie <rpurdie@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Will Newton [Wed, 24 Nov 2010 20:56:55 +0000 (12:56 -0800)]
uml: disable winch irq before freeing handler data
commit
69e83dad5207f8f03c9699e57e1febb114383cb8 upstream.
Disable the winch irq early to make sure we don't take an interrupt part
way through the freeing of the handler data, resulting in a crash on
shutdown:
winch_interrupt : read failed, errno = 9
fd 13 is losing SIGWINCH support
------------[ cut here ]------------
WARNING: at lib/list_debug.c:48 list_del+0xc6/0x100()
list_del corruption, next is LIST_POISON1 (
00100100)
082578c8: [<
081fd77f>] dump_stack+0x22/0x24
082578e0: [<
0807a18a>] warn_slowpath_common+0x5a/0x80
08257908: [<
0807a23e>] warn_slowpath_fmt+0x2e/0x30
08257920: [<
08172196>] list_del+0xc6/0x100
08257940: [<
08060244>] free_winch+0x14/0x80
08257958: [<
080606fb>] winch_interrupt+0xdb/0xe0
08257978: [<
080a65b5>] handle_IRQ_event+0x35/0xe0
08257998: [<
080a8717>] handle_edge_irq+0xb7/0x170
082579bc: [<
08059bc4>] do_IRQ+0x34/0x50
082579d4: [<
08059e1b>] sigio_handler+0x5b/0x80
082579ec: [<
0806a374>] sig_handler_common+0x44/0xb0
08257a68: [<
0806a538>] sig_handler+0x38/0x50
08257a78: [<
0806a77c>] handle_signal+0x5c/0xa0
08257a9c: [<
0806be28>] hard_handler+0x18/0x20
08257aac: [<
00c14400>] 0xc14400
Signed-off-by: Will Newton <will.newton@gmail.com>
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Nelson Elhage [Thu, 2 Dec 2010 22:31:21 +0000 (14:31 -0800)]
do_exit(): make sure that we run with get_fs() == USER_DS
commit
33dd94ae1ccbfb7bf0fb6c692bc3d1c4269e6177 upstream.
If a user manages to trigger an oops with fs set to KERNEL_DS, fs is not
otherwise reset before do_exit(). do_exit may later (via mm_release in
fork.c) do a put_user to a user-controlled address, potentially allowing
a user to leverage an oops into a controlled write into kernel memory.
This is only triggerable in the presence of another bug, but this
potentially turns a lot of DoS bugs into privilege escalations, so it's
worth fixing. I have proof-of-concept code which uses this bug along
with CVE-2010-3849 to write a zero to an arbitrary kernel address, so
I've tested that this is not theoretical.
A more logical place to put this fix might be when we know an oops has
occurred, before we call do_exit(), but that would involve changing
every architecture, in multiple places.
Let's just stick it in do_exit instead.
[akpm@linux-foundation.org: update code comment]
Signed-off-by: Nelson Elhage <nelhage@ksplice.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ken Sumrall [Wed, 24 Nov 2010 20:57:00 +0000 (12:57 -0800)]
fuse: fix attributes after open(O_TRUNC)
commit
a0822c55779d9319939eac69f00bb729ea9d23da upstream.
The attribute cache for a file was not being cleared when a file is opened
with O_TRUNC.
If the filesystem's open operation truncates the file ("atomic_o_trunc"
feature flag is set) then the kernel should invalidate the cached st_mtime
and st_ctime attributes.
Also i_size should be explicitly be set to zero as it is used sometimes
without refreshing the cache.
Signed-off-by: Ken Sumrall <ksumrall@android.com>
Cc: Anfei <anfei.zhou@gmail.com>
Cc: "Anand V. Avati" <avati@gluster.com>
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Len Brown [Tue, 28 Sep 2010 21:51:51 +0000 (17:51 -0400)]
ACPI: EC: add Vista incompatibility DMI entry for Toshiba Satellite L355
commit
7a1d602f5fc35d14907b7da98d5627acb69589d1 upstream.
https://bugzilla.kernel.org/show_bug.cgi?id=12641
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Zhang Rui [Tue, 12 Oct 2010 01:09:37 +0000 (09:09 +0800)]
acpi-cpufreq: fix a memleak when unloading driver
commit
dab5fff14df2cd16eb1ad4c02e83915e1063fece upstream.
We didn't free per_cpu(acfreq_data, cpu)->freq_table
when acpi_freq driver is unloaded.
Resulting in the following messages in /sys/kernel/debug/kmemleak:
unreferenced object 0xf6450e80 (size 64):
comm "modprobe", pid 1066, jiffies
4294677317 (age 19290.453s)
hex dump (first 32 bytes):
00 00 00 00 e8 a2 24 00 01 00 00 00 00 9f 24 00 ......$.......$.
02 00 00 00 00 6a 18 00 03 00 00 00 00 35 0c 00 .....j.......5..
backtrace:
[<
c123ba97>] kmemleak_alloc+0x27/0x50
[<
c109f96f>] __kmalloc+0xcf/0x110
[<
f9da97ee>] acpi_cpufreq_cpu_init+0x1ee/0x4e4 [acpi_cpufreq]
[<
c11cd8d2>] cpufreq_add_dev+0x142/0x3a0
[<
c11920b7>] sysdev_driver_register+0x97/0x110
[<
c11cce56>] cpufreq_register_driver+0x86/0x140
[<
f9dad080>] 0xf9dad080
[<
c1001130>] do_one_initcall+0x30/0x160
[<
c10626e9>] sys_init_module+0x99/0x1e0
[<
c1002d97>] sysenter_do_call+0x12/0x26
[<
ffffffff>] 0xffffffff
https://bugzilla.kernel.org/show_bug.cgi?id=15807#c21
Tested-by: Toralf Forster <toralf.foerster@gmx.de>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jacques Viviers [Wed, 24 Nov 2010 09:56:38 +0000 (11:56 +0200)]
USB: serial: ftdi_sio: Vardaan USB RS422/485 converter PID added
commit
6fdbad8021151a9e93af8159a6232c8f26415c09 upstream.
Add the PID for the Vardaan Enterprises VEUSB422R3 USB to RS422/485
converter. It uses the same chip as the FTDI_8U232AM_PID 0x6001.
This should also work with the stable branches for:
2.6.31, 2.6.32, 2.6.33, 2.6.34, 2.6.35, 2.6.36
Signed-off-by: Jacques Viviers <jacques.viviers@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Michael Stuermer [Wed, 17 Nov 2010 23:45:43 +0000 (00:45 +0100)]
USB: ftdi_sio: Add ID for RT Systems USB-29B radio cable
commit
28942bb6a9dd4e2ed793675e515cfb8297ed355b upstream.
Another variant of the RT Systems programming cable for ham radios.
Signed-off-by: Michael Stuermer <ms@mallorn.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Mon, 15 Nov 2010 19:36:44 +0000 (11:36 -0800)]
USB: misc: usbsevseg: fix up some sysfs attribute permissions
commit
e24d7ace4e822debcb78386bf279c9aba4d7fbd1 upstream.
They should not be writable by any user.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Harrison Metzger <harrisonmetz@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Mon, 15 Nov 2010 19:34:26 +0000 (11:34 -0800)]
USB: misc: trancevibrator: fix up a sysfs attribute permission
commit
d489a4b3926bad571d404ca6508f6744b9602776 upstream.
It should not be writable by any user.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Sam Hocevar <sam@zoy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Johan Hovold [Sun, 12 Sep 2010 14:31:45 +0000 (16:31 +0200)]
USB: ftdi_sio: revert "USB: ftdi_sio: fix DTR/RTS line modes"
commit
677aeafe19e88c282af74564048243ccabb1c590 upstream.
This reverts commit
6a1a82df91fa0eb1cc76069a9efe5714d087eccd.
RTS and DTR should not be modified based on CRTSCTS when calling
set_termios.
Modem control lines are raised at port open by the tty layer and should stay
raised regardless of whether hardware flow control is enabled or not.
This is in conformance with the way serial ports work today and many
applications depend on this behaviour to be able to talk to hardware
implementing hardware flow control (without the applications actually using
it).
Hardware which expects different behaviour on these lines can always
use TIOCMSET/TIOCMBI[SC] after port open to change them.
Reported-by: Daniel Mack <daniel@caiaq.de>
Reported-by: Dave Mielke <dave@mielke.cc>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Mon, 15 Nov 2010 19:35:49 +0000 (11:35 -0800)]
USB: misc: usbled: fix up some sysfs attribute permissions
commit
48f115470e68d443436b76b22dad63ffbffd6b97 upstream.
They should not be writable by any user.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Mon, 15 Nov 2010 19:32:38 +0000 (11:32 -0800)]
USB: misc: cypress_cy7c63: fix up some sysfs attribute permissions
commit
c990600d340641150f7270470a64bd99a5c0b225 upstream.
They should not be writable by any user.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oliver Bock <bock@tfh-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Mon, 15 Nov 2010 19:11:45 +0000 (11:11 -0800)]
USB: atm: ueagle-atm: fix up some permissions on the sysfs files
commit
e502ac5e1eca99d7dc3f12b2a6780ccbca674858 upstream.
Some of the sysfs files had the incorrect permissions. Some didn't make
sense at all (writable for a file that you could not write to?)
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthieu Castet <castet.matthieu@free.fr>
Cc: Stanislaw Gruszka <stf_xl@wp.pl>
Cc: Damien Bergamini <damien.bergamini@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Mon, 15 Nov 2010 19:17:52 +0000 (11:17 -0800)]
USB: storage: sierra_ms: fix sysfs file attribute
commit
d9624e75f6ad94d8a0718c1fafa89186d271a78c upstream.
A non-writable sysfs file shouldn't have writable attributes.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Kevin Lloyd <klloyd@sierrawireless.com>
Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern [Tue, 16 Nov 2010 15:57:37 +0000 (10:57 -0500)]
USB: EHCI: fix obscure race in ehci_endpoint_disable
commit
02e2c51ba3e80acde600721ea784c3ef84da5ea1 upstream.
This patch (as1435) fixes an obscure and unlikely race in ehci-hcd.
When an async URB is unlinked, the corresponding QH is removed from
the async list. If the QH's endpoint is then disabled while the URB
is being given back, ehci_endpoint_disable() won't find the QH on the
async list, causing it to believe that the QH has been lost. This
will lead to a memory leak at best and quite possibly to an oops.
The solution is to trust usbcore not to lose track of endpoints. If
the QH isn't on the async list then it doesn't need to be taken off
the list, but the driver should still wait for the QH to become IDLE
before disabling it.
In theory this fixes Bugzilla #20182. In fact the race is so rare
that it's not possible to tell whether the bug is still present.
However, adding delays and making other changes to force the race
seems to show that the patch works.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Vasiliy Kulikov [Sat, 6 Nov 2010 14:41:28 +0000 (17:41 +0300)]
usb: core: fix information leak to userland
commit
886ccd4520064408ce5876cfe00554ce52ecf4a7 upstream.
Structure usbdevfs_connectinfo is copied to userland with padding byted
after "slow" field uninitialized. It leads to leaking of contents of
kernel stack memory.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Vasiliy Kulikov [Sat, 6 Nov 2010 14:41:31 +0000 (17:41 +0300)]
usb: misc: iowarrior: fix information leak to userland
commit
eca67aaeebd6e5d22b0d991af1dd0424dc703bfb upstream.
Structure iowarrior_info is copied to userland with padding byted
between "serial" and "revision" fields uninitialized. It leads to
leaking of contents of kernel stack memory.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Acked-by: Kees Cook <kees.cook@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>