Linux 3.0.65

commit fe34c843d97c4fa082fe66dc3a65e7bd5603c70c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Feb 17 10:46:34 2013 -0800

    Linux 3.0.65

commit f4dc0e6ec906da70d1edf6d00f49b792f47f2efd
Author: Alexander Duyck <alexander.h.duyck@intel.com>
Date:   Wed Aug 8 05:23:22 2012 +0000

    igb: Remove artificial restriction on RQDPC stat reading

    commit ae1c07a6b7ced6c0c94c99e3b53f4e7856fa8bff upstream.

    For some reason the reading of the RQDPC register was being artificially
    limited to 4K.  Instead of limiting the value we should read the value and
    add the full amount.  Otherwise this can lead to a misleading number of
    dropped packets when the actual value is in fact much higher.

    Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
    Tested-by: Jeff Pieper   <jeffrey.e.pieper@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Cc: Vinson Lee <vlee@twitter.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e862f5583a92ac9680bdb18a0e5dffe2a2c3d464
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Mon Feb 11 20:49:49 2013 +0100

    PCI/PM: Clean up PME state when removing a device

    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 <daniel@quora.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3339af37f35aff045db6a830185dddfac424c937
Author: Jan Beulich <JBeulich@suse.com>
Date:   Thu Jan 24 13:11:10 2013 +0000

    x86/xen: don't assume %ds is usable in xen_iret for 32-bit PVOPS.

    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:[<c0407462>] 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: [<c0407462>] 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:
     [<c08476df>] ? panic+0x6e/0x122
     [<c084b63c>] ? oops_end+0xbc/0xd0
     [<c084b260>] ? do_general_protection+0x0/0x210
     [<c084a9b7>] ? 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 <pmatouse@redhat.com>
    Reported-by: Petr Matousek <pmatouse@redhat.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec3918604c896df59632d47bd2ed874cbc2f262b
Author: Mel Gorman <mgorman@suse.de>
Date:   Mon Feb 11 14:52:36 2013 +0000

    x86/mm: Check if PUD is large when validating a kernel address

    commit 0ee364eb316348ddf3e0dfcd986f5f13f528f821 upstream.

    A user reported the following oops when a backup process reads
    /proc/kcore:

     BUG: unable to handle kernel paging request at ffffbb00ff33b000
     IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
     [...]

     Call Trace:
      [<ffffffff811b8aaa>] read_kcore+0x17a/0x370
      [<ffffffff811ad847>] proc_reg_read+0x77/0xc0
      [<ffffffff81151687>] vfs_read+0xc7/0x130
      [<ffffffff811517f3>] sys_read+0x53/0xa0
      [<ffffffff81449692>] system_call_fastpath+0x16/0x1b

    Investigation determined that the bug triggered when reading
    system RAM at the 4G mark. On this system, that was the first
    address using 1G pages for the virt->phys direct mapping so the
    PUD is pointing to a physical address, not a PMD page.

    The problem is that the page table walker in kern_addr_valid() is
    not checking pud_large() and treats the physical address as if
    it was a PMD.  If it happens to look like pmd_none then it'll
    silently fail, probably returning zeros instead of real data. If
    the data happens to look like a present PMD though, it will be
    walked resulting in the oops above.

    This patch adds the necessary pud_large() check.

    Unfortunately the problem was not readily reproducible and now
    they are running the backup program without accessing
    /proc/kcore so the patch has not been validated but I think it
    makes sense.

    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Reviewed-by: Rik van Riel <riel@redhat.coM>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: linux-mm@kvack.org
    Link: http://lkml.kernel.org/r/20130211145236.GX21389@suse.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>