From: Greg Kroah-Hartman Date: Fri, 15 Feb 2013 22:10:15 +0000 (-0800) Subject: 3.7-stable patches X-Git-Tag: v3.0.65~3 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=f2a54d60639c573a16d85a7a70ecea38f63c0563;p=thirdparty%2Fkernel%2Fstable-queue.git 3.7-stable patches added patches: efi-clear-efi_runtime_services-rather-than-efi_boot-by-noefi-boot-parameter.patch pci-pm-clean-up-pme-state-when-removing-a-device.patch x86-xen-don-t-assume-ds-is-usable-in-xen_iret-for-32-bit-pvops.patch --- diff --git a/queue-3.7/efi-clear-efi_runtime_services-rather-than-efi_boot-by-noefi-boot-parameter.patch b/queue-3.7/efi-clear-efi_runtime_services-rather-than-efi_boot-by-noefi-boot-parameter.patch new file mode 100644 index 00000000000..964811b2882 --- /dev/null +++ b/queue-3.7/efi-clear-efi_runtime_services-rather-than-efi_boot-by-noefi-boot-parameter.patch @@ -0,0 +1,67 @@ +From 1de63d60cd5b0d33a812efa455d5933bf1564a51 Mon Sep 17 00:00:00 2001 +From: Satoru Takeuchi +Date: Thu, 14 Feb 2013 09:12:52 +0900 +Subject: efi: Clear EFI_RUNTIME_SERVICES rather than EFI_BOOT by "noefi" boot parameter + +From: Satoru Takeuchi + +commit 1de63d60cd5b0d33a812efa455d5933bf1564a51 upstream. + +There was a serious problem in samsung-laptop that its platform driver is +designed to run under BIOS and running under EFI can cause the machine to +become bricked or can cause Machine Check Exceptions. + + Discussion about this problem: + https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557 + https://bugzilla.kernel.org/show_bug.cgi?id=47121 + + The patches to fix this problem: + efi: Make 'efi_enabled' a function to query EFI facilities + 83e68189745ad931c2afd45d8ee3303929233e7f + + samsung-laptop: Disable on EFI hardware + e0094244e41c4d0c7ad69920681972fc45d8ce34 + +Unfortunately this problem comes back again if users specify "noefi" option. +This parameter clears EFI_BOOT and that driver continues to run even if running +under EFI. Refer to the document, this parameter should clear +EFI_RUNTIME_SERVICES instead. + +Documentation/kernel-parameters.txt: +=============================================================================== +... + noefi [X86] Disable EFI runtime services support. +... +=============================================================================== + +Documentation/x86/x86_64/uefi.txt: +=============================================================================== +... +- If some or all EFI runtime services don't work, you can try following + kernel command line parameters to turn off some or all EFI runtime + services. + noefi turn off all EFI runtime services +... +=============================================================================== + +Signed-off-by: Satoru Takeuchi +Link: http://lkml.kernel.org/r/511C2C04.2070108@jp.fujitsu.com +Cc: Matt Fleming +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/platform/efi/efi.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/platform/efi/efi.c ++++ b/arch/x86/platform/efi/efi.c +@@ -87,7 +87,7 @@ EXPORT_SYMBOL(efi_enabled); + + static int __init setup_noefi(char *arg) + { +- clear_bit(EFI_BOOT, &x86_efi_facility); ++ clear_bit(EFI_RUNTIME_SERVICES, &x86_efi_facility); + return 0; + } + early_param("noefi", setup_noefi); diff --git a/queue-3.7/pci-pm-clean-up-pme-state-when-removing-a-device.patch b/queue-3.7/pci-pm-clean-up-pme-state-when-removing-a-device.patch new file mode 100644 index 00000000000..78d153fa155 --- /dev/null +++ b/queue-3.7/pci-pm-clean-up-pme-state-when-removing-a-device.patch @@ -0,0 +1,45 @@ +From 249bfb83cf8ba658955f0245ac3981d941f746ee Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Mon, 11 Feb 2013 20:49:49 +0100 +Subject: PCI/PM: Clean up PME state when removing a device + +From: "Rafael J. Wysocki" + +commit 249bfb83cf8ba658955f0245ac3981d941f746ee upstream. + +Devices are added to pci_pme_list when drivers use pci_enable_wake() +or pci_wake_from_d3(), but they aren't removed from the list unless +the driver explicitly disables wakeup. Many drivers never disable +wakeup, so their devices remain on the list even after they are +removed, e.g., via hotplug. A subsequent PME poll will oops when +it tries to touch the device. + +This patch disables PME# on a device before removing it, which removes +the device from pci_pme_list. This is safe even if the device never +had PME# enabled. + +This oops can be triggered by unplugging a Thunderbolt ethernet adapter +on a Macbook Pro, as reported by Daniel below. + +[bhelgaas: changelog] +Reference: http://lkml.kernel.org/r/CAMVG2svG21yiM1wkH4_2pen2n+cr2-Zv7TbH3Gj+8MwevZjDbw@mail.gmail.com +Reported-and-tested-by: Daniel J Blueman +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Bjorn Helgaas +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/remove.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/pci/remove.c ++++ b/drivers/pci/remove.c +@@ -19,6 +19,8 @@ static void pci_free_resources(struct pc + + static void pci_stop_dev(struct pci_dev *dev) + { ++ pci_pme_active(dev, false); ++ + if (dev->is_added) { + pci_proc_detach_device(dev); + pci_remove_sysfs_dev_files(dev); diff --git a/queue-3.7/series b/queue-3.7/series index 0f010020456..de46bf27d77 100644 --- a/queue-3.7/series +++ b/queue-3.7/series @@ -5,3 +5,6 @@ s390-timer-avoid-overflow-when-programming-clock-comparator.patch x86-do-not-leak-kernel-page-mapping-locations.patch x86-apic-work-around-boot-failure-on-hp-proliant-dl980-g7-server-systems.patch x86-mm-check-if-pud-is-large-when-validating-a-kernel-address.patch +x86-xen-don-t-assume-ds-is-usable-in-xen_iret-for-32-bit-pvops.patch +pci-pm-clean-up-pme-state-when-removing-a-device.patch +efi-clear-efi_runtime_services-rather-than-efi_boot-by-noefi-boot-parameter.patch diff --git a/queue-3.7/x86-xen-don-t-assume-ds-is-usable-in-xen_iret-for-32-bit-pvops.patch b/queue-3.7/x86-xen-don-t-assume-ds-is-usable-in-xen_iret-for-32-bit-pvops.patch new file mode 100644 index 00000000000..a392ef0c7b1 --- /dev/null +++ b/queue-3.7/x86-xen-don-t-assume-ds-is-usable-in-xen_iret-for-32-bit-pvops.patch @@ -0,0 +1,131 @@ +From 13d2b4d11d69a92574a55bfd985cfb0ca77aebdc Mon Sep 17 00:00:00 2001 +From: Jan Beulich +Date: Thu, 24 Jan 2013 13:11:10 +0000 +Subject: x86/xen: don't assume %ds is usable in xen_iret for 32-bit PVOPS. + +From: Jan Beulich + +commit 13d2b4d11d69a92574a55bfd985cfb0ca77aebdc upstream. + +This fixes CVE-2013-0228 / XSA-42 + +Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user +in 32bit PV guest can use to crash the > guest with the panic like this: + +------------- +general protection fault: 0000 [#1] SMP +last sysfs file: /sys/devices/vbd-51712/block/xvda/dev +Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 +iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 +xt_state nf_conntrack ip6table_filter ip6_tables ipv6 xen_netfront ext4 +mbcache jbd2 xen_blkfront dm_mirror dm_region_hash dm_log dm_mod [last +unloaded: scsi_wait_scan] + +Pid: 1250, comm: r Not tainted 2.6.32-356.el6.i686 #1 +EIP: 0061:[] EFLAGS: 00010086 CPU: 0 +EIP is at xen_iret+0x12/0x2b +EAX: eb8d0000 EBX: 00000001 ECX: 08049860 EDX: 00000010 +ESI: 00000000 EDI: 003d0f00 EBP: b77f8388 ESP: eb8d1fe0 + DS: 0000 ES: 007b FS: 0000 GS: 00e0 SS: 0069 +Process r (pid: 1250, ti=eb8d0000 task=c2953550 task.ti=eb8d0000) +Stack: + 00000000 0027f416 00000073 00000206 b77f8364 0000007b 00000000 00000000 +Call Trace: +Code: c3 8b 44 24 18 81 4c 24 38 00 02 00 00 8d 64 24 30 e9 03 00 00 00 +8d 76 00 f7 44 24 08 00 00 02 80 75 33 50 b8 00 e0 ff ff 21 e0 <8b> 40 +10 8b 04 85 a0 f6 ab c0 8b 80 0c b0 b3 c0 f6 44 24 0d 02 +EIP: [] xen_iret+0x12/0x2b SS:ESP 0069:eb8d1fe0 +general protection fault: 0000 [#2] +---[ end trace ab0d29a492dcd330 ]--- +Kernel panic - not syncing: Fatal exception +Pid: 1250, comm: r Tainted: G D --------------- +2.6.32-356.el6.i686 #1 +Call Trace: + [] ? panic+0x6e/0x122 + [] ? oops_end+0xbc/0xd0 + [] ? do_general_protection+0x0/0x210 + [] ? error_code+0x73/ +------------- + +Petr says: " + I've analysed the bug and I think that xen_iret() cannot cope with + mangled DS, in this case zeroed out (null selector/descriptor) by either + xen_failsafe_callback() or RESTORE_REGS because the corresponding LDT + entry was invalidated by the reproducer. " + +Jan took a look at the preliminary patch and came up a fix that solves +this problem: + +"This code gets called after all registers other than those handled by +IRET got already restored, hence a null selector in %ds or a non-null +one that got loaded from a code or read-only data descriptor would +cause a kernel mode fault (with the potential of crashing the kernel +as a whole, if panic_on_oops is set)." + +The way to fix this is to realize that the we can only relay on the +registers that IRET restores. The two that are guaranteed are the +%cs and %ss as they are always fixed GDT selectors. Also they are +inaccessible from user mode - so they cannot be altered. This is +the approach taken in this patch. + +Another alternative option suggested by Jan would be to relay on +the subtle realization that using the %ebp or %esp relative references uses +the %ss segment. In which case we could switch from using %eax to %ebp and +would not need the %ss over-rides. That would also require one extra +instruction to compensate for the one place where the register is used +as scaled index. However Andrew pointed out that is too subtle and if +further work was to be done in this code-path it could escape folks attention +and lead to accidents. + +Reviewed-by: Petr Matousek +Reported-by: Petr Matousek +Reviewed-by: Andrew Cooper +Signed-off-by: Jan Beulich +Signed-off-by: Konrad Rzeszutek Wilk +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/xen/xen-asm_32.S | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +--- a/arch/x86/xen/xen-asm_32.S ++++ b/arch/x86/xen/xen-asm_32.S +@@ -89,11 +89,11 @@ ENTRY(xen_iret) + */ + #ifdef CONFIG_SMP + GET_THREAD_INFO(%eax) +- movl TI_cpu(%eax), %eax +- movl __per_cpu_offset(,%eax,4), %eax +- mov xen_vcpu(%eax), %eax ++ movl %ss:TI_cpu(%eax), %eax ++ movl %ss:__per_cpu_offset(,%eax,4), %eax ++ mov %ss:xen_vcpu(%eax), %eax + #else +- movl xen_vcpu, %eax ++ movl %ss:xen_vcpu, %eax + #endif + + /* check IF state we're restoring */ +@@ -106,11 +106,11 @@ ENTRY(xen_iret) + * resuming the code, so we don't have to be worried about + * being preempted to another CPU. + */ +- setz XEN_vcpu_info_mask(%eax) ++ setz %ss:XEN_vcpu_info_mask(%eax) + xen_iret_start_crit: + + /* check for unmasked and pending */ +- cmpw $0x0001, XEN_vcpu_info_pending(%eax) ++ cmpw $0x0001, %ss:XEN_vcpu_info_pending(%eax) + + /* + * If there's something pending, mask events again so we can +@@ -118,7 +118,7 @@ xen_iret_start_crit: + * touch XEN_vcpu_info_mask. + */ + jne 1f +- movb $1, XEN_vcpu_info_mask(%eax) ++ movb $1, %ss:XEN_vcpu_info_mask(%eax) + + 1: popl %eax +