linux-stable.git, branch v3.0.62

Linux 3.0.62

2013-02-04T00:22:00+00:00

x86/Sandy Bridge: Sandy Bridge workaround depends on CONFIG_PCI

2013-02-04T00:21:38+00:00

commit e43b3cec711a61edf047adf6204d542f3a659ef8 upstream.

early_pci_allowed() and read_pci_config_16() are only available if
CONFIG_PCI is defined.

Signed-off-by: H. Peter Anvin 
Cc: Jesse Barnes 
Signed-off-by: Abdallah Chatila

efi, x86: Pass a proper identity mapping in efi_call_phys_prelog

2013-02-04T00:21:38+00:00

commit b8f2c21db390273c3eaf0e5308faeaeb1e233840 upstream.

Update efi_call_phys_prelog to install an identity mapping of all available
memory.  This corrects a bug on very large systems with more then 512 GB in
which bios would not be able to access addresses above not in the mapping.

The result is a crash that looks much like this.

BUG: unable to handle kernel paging request at 000000effd870020
IP: [<0000000078bce331>] 0x78bce330
PGD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU 0
Pid: 0, comm: swapper/0 Tainted: G        W    3.8.0-rc1-next-20121224-medusa_ntz+ #2 Intel Corp. Stoutland Platform
RIP: 0010:[<0000000078bce331>]  [<0000000078bce331>] 0x78bce330
RSP: 0000:ffffffff81601d28  EFLAGS: 00010006
RAX: 0000000078b80e18 RBX: 0000000000000004 RCX: 0000000000000004
RDX: 0000000078bcf958 RSI: 0000000000002400 RDI: 8000000000000000
RBP: 0000000078bcf760 R08: 000000effd870000 R09: 0000000000000000
R10: 0000000000000000 R11: 00000000000000c3 R12: 0000000000000030
R13: 000000effd870000 R14: 0000000000000000 R15: ffff88effd870000
FS:  0000000000000000(0000) GS:ffff88effe400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000effd870020 CR3: 000000000160c000 CR4: 00000000000006b0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper/0 (pid: 0, threadinfo ffffffff81600000, task ffffffff81614400)
Stack:
 0000000078b80d18 0000000000000004 0000000078bced7b ffff880078b81fff
 0000000000000000 0000000000000082 0000000078bce3a8 0000000000002400
 0000000060000202 0000000078b80da0 0000000078bce45d ffffffff8107cb5a
Call Trace:
 [] ? on_each_cpu+0x77/0x83
 [] ? change_page_attr_set_clr+0x32f/0x3ed
 [] ? efi_call4+0x46/0x80
 [] ? efi_enter_virtual_mode+0x1f5/0x305
 [] ? start_kernel+0x34a/0x3d2
 [] ? repair_env_string+0x60/0x60
 [] ? x86_64_start_reservations+0xba/0xc1
 [] ? early_idt_handlers+0x120/0x120
 [] ? x86_64_start_kernel+0x154/0x163
Code:  Bad RIP value.
RIP  [<0000000078bce331>] 0x78bce330
 RSP 
CR2: 000000effd870020
---[ end trace ead828934fef5eab ]---

Signed-off-by: Nathan Zimmer 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Signed-off-by: Robin Holt 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

x86/msr: Add capabilities check

2013-02-04T00:21:38+00:00

commit c903f0456bc69176912dee6dd25c6a66ee1aed00 upstream.

At the moment the MSR driver only relies upon file system
checks. This means that anything as root with any capability set
can write to MSRs. Historically that wasn't very interesting but
on modern processors the MSRs are such that writing to them
provides several ways to execute arbitary code in kernel space.
Sample code and documentation on doing this is circulating and
MSR attacks are used on Windows 64bit rootkits already.

In the Linux case you still need to be able to open the device
file so the impact is fairly limited and reduces the security of
some capability and security model based systems down towards
that of a generic "root owns the box" setup.

Therefore they should require CAP_SYS_RAWIO to prevent an
elevation of capabilities. The impact of this is fairly minimal
on most setups because they don't have heavy use of
capabilities. Those using SELinux, SMACK or AppArmor rules might
want to consider if their rulesets on the MSR driver could be
tighter.

Signed-off-by: Alan Cox 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Peter Zijlstra 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

smp: Fix SMP function call empty cpu mask race

2013-02-04T00:21:38+00:00

commit f44310b98ddb7f0d06550d73ed67df5865e3eda5 upstream.

I get the following warning every day with v3.7, once or
twice a day:

  [ 2235.186027] WARNING: at /mnt/sda7/kernel/linux/arch/x86/kernel/apic/ipi.c:109 default_send_IPI_mask_logical+0x2f/0xb8()

As explained by Linus as well:

 |
 | Once we've done the "list_add_rcu()" to add it to the
 | queue, we can have (another) IPI to the target CPU that can
 | now see it and clear the mask.
 |
 | So by the time we get to actually send the IPI, the mask might
 | have been cleared by another IPI.
 |

This patch also fixes a system hang problem, if the data->cpumask
gets cleared after passing this point:

        if (WARN_ONCE(!mask, "empty IPI mask"))
                return;

then the problem in commit 83d349f35e1a ("x86: don't send an IPI to
the empty set of CPU's") will happen again.

Signed-off-by: Wang YanQing 
Acked-by: Linus Torvalds 
Acked-by: Jan Beulich 
Cc: Paul E. McKenney 
Cc: Andrew Morton 
Cc: peterz@infradead.org
Cc: mina86@mina86.org
Cc: srivatsa.bhat@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/20130126075357.GA3205@udknight
[ Tidied up the changelog and the comment in the code. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix incorrect strncpy() in hidp_setup_hid()

2013-02-04T00:21:37+00:00

commit 0a9ab9bdb3e891762553f667066190c1d22ad62b upstream.

The length parameter should be sizeof(req->name) - 1 because there is no
guarantee that string provided by userspace will contain the trailing
'\0'.

Can be easily reproduced by manually setting req->name to 128 non-zero
bytes prior to ioctl(HIDPCONNADD) and checking the device name setup on
input subsystem:

$ cat /sys/devices/pnp0/00\:04/tty/ttyS0/hci0/hci0\:1/input8/name
AAAAAA[...]AAAAAAAAf0:af:f0:af:f0:af

("f0:af:f0:af:f0:af" is the device bluetooth address, taken from "phys"
field in struct hid_device due to overflow.)

Signed-off-by: Anderson Lizardo 
Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Greg Kroah-Hartman

EDAC: Test correct variable in ->store function

2013-02-04T00:21:37+00:00

commit 8024c4c0b1057d1cd811fc9c3f88f81de9729fcd upstream.

We're testing for ->show but calling ->store().

Signed-off-by: Dan Carpenter 
Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: fix invalid length check for RME and other UAC 2 devices

2013-02-04T00:21:37+00:00

commit d56268fb108c7c21e19933588ca4d94652585183 upstream.

Commit 23caaf19b11e (ALSA: usb-mixer: Add support for Audio Class v2.0)
forgot to adjust the length check for UAC 2.0 feature unit descriptors.
This would make the code abort on encountering a feature unit without
per-channel controls, and thus prevented the driver to work with any
device having such a unit, such as the RME Babyface or Fireface UCX.

Reported-by: Florian Hanisch 
Tested-by: Matthew Robbetts 
Tested-by: Michael Beer 
Cc: Daniel Mack 
Signed-off-by: Clemens Ladisch 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ath9k: fix double-free bug on beacon generate failure

2013-02-04T00:21:37+00:00

commit 1adb2e2b5f85023d17eb4f95386a57029df27c88 upstream.

When the next beacon is sent, the ath_buf from the previous run is reused.
If getting a new beacon from mac80211 fails, bf->bf_mpdu is not reset, yet
the skb is freed, leading to a double-free on the next beacon tx attempt,
resulting in a system crash.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k_htc: Fix memory leak

2013-02-04T00:21:37+00:00

commit 0981c3b24ef664f5611008a6e6d0622fac6d892b upstream.

SKBs that are allocated in the HTC layer do not have callbacks
registered and hence ended up not being freed, Fix this by freeing
them properly in the TX completion routine.

Reported-by: Larry Finger 
Signed-off-by: Sujith Manoharan 
Tested-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman