Linux v3.7.9
This commit is contained in:
Justin M. Forbes
parent
f82ba77f45
commit
d338b6bb72
17
kernel.spec
17
kernel.spec
|
|
@ -62,7 +62,7 @@ Summary: The Linux kernel
|
|||
# For non-released -rc kernels, this will be appended after the rcX and
|
||||
# gitX tags, so a 3 here would become part of release "0.rcX.gitX.3"
|
||||
#
|
||||
%global baserelease 202
|
||||
%global baserelease 201
|
||||
%global fedora_build %{baserelease}
|
||||
|
||||
# base_sublevel is the kernel version we're starting with and patching
|
||||
|
|
@ -74,7 +74,7 @@ Summary: The Linux kernel
|
|||
%if 0%{?released_kernel}
|
||||
|
||||
# Do we have a -stable update to apply?
|
||||
%define stable_update 8
|
||||
%define stable_update 9
|
||||
# Is it a -stable RC?
|
||||
%define stable_rc 0
|
||||
# Set rpm version accordingly
|
||||
|
|
@ -790,16 +790,11 @@ Patch22241: Input-add-support-for-Cypress-PS2-Trackpads.patch
|
|||
#rhbz 892811
|
||||
Patch22247: ath9k_rx_dma_stop_check.patch
|
||||
|
||||
#rhbz 906309 910848 CVE-2013-0228
|
||||
Patch21248: xen-dont-assume-ds-is-usable-in-xen_iret-for-32-bit-PVOPS.patch
|
||||
|
||||
#rhbz 911479 911473 CVE-2013-0290
|
||||
Patch22256: net-fix-infinite-loop-in-__skb_recv_datagram.patch
|
||||
|
||||
Patch23000: silence-brcmsmac-warning.patch
|
||||
|
||||
Patch23100: validate-pud-largepage.patch
|
||||
|
||||
#rhbz 909591
|
||||
Patch21255: usb-cypress-supertop.patch
|
||||
|
||||
|
|
@ -1528,11 +1523,6 @@ ApplyPatch ath9k_rx_dma_stop_check.patch
|
|||
|
||||
ApplyPatch silence-brcmsmac-warning.patch
|
||||
|
||||
ApplyPatch validate-pud-largepage.patch
|
||||
|
||||
#rhbz 906309 910848 CVE-2013-0228
|
||||
ApplyPatch xen-dont-assume-ds-is-usable-in-xen_iret-for-32-bit-PVOPS.patch
|
||||
|
||||
#rhbz 909591
|
||||
ApplyPatch usb-cypress-supertop.patch
|
||||
|
||||
|
|
@ -2402,6 +2392,9 @@ fi
|
|||
# ||----w |
|
||||
# || ||
|
||||
%changelog
|
||||
* Mon Feb 18 2013 Justin M. Forbes <jforbes@redhat.com> - 3.7.9-201
|
||||
- Linux v3.7.9
|
||||
|
||||
* Mon Feb 18 2013 Adam Jackson <ajax@redhat.com
|
||||
- i915: Fix a mismerge in 3.7.y that leads to divide-by-zero in i915_update_wm
|
||||
|
||||
|
|
|
|||
2
sources
2
sources
|
|
@ -1,2 +1,2 @@
|
|||
21223369d682bcf44bcdfe1521095983 linux-3.7.tar.xz
|
||||
bf62e0cbc13524bb802d2ed05c7e2e6a patch-3.7.8.xz
|
||||
375fa67b3daba9e6040f13a0a29bf543 patch-3.7.9.xz
|
||||
|
|
|
|||
|
|
@ -1,102 +0,0 @@
|
|||
Date: Mon, 11 Feb 2013 14:52:36 +0000
|
||||
From: Mel Gorman <mgorman@suse.de>
|
||||
To: Ingo Molnar <mingo@kernel.org>, Andrew Morton <akpm@linux-foundation.org>
|
||||
Cc: Mel Gorman <mgorman@suse.de>, linux-kernel@vger.kernel.org, linux-mm@kvack.org
|
||||
Subject: [PATCH] x86: mm: Check if PUD is large when validating a kernel address
|
||||
Message-ID: <20130211145236.GX21389@suse.de>
|
||||
MIME-Version: 1.0
|
||||
|
||||
A user reported the following oops when a backup process read
|
||||
/proc/kcore.
|
||||
|
||||
BUG: unable to handle kernel paging request at ffffbb00ff33b000
|
||||
IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
|
||||
PGD 0
|
||||
Oops: 0000 [#1] SMP
|
||||
CPU 6
|
||||
Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc 8021q garp stp llc cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf microcode fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod ioatdma ipv6 ipv6_lib igb dca i7core_edac edac_core i2c_i801 i2c_core cdc_ether usbnet bnx2 mii iTCO_wdt iTCO_vendor_support shpchp rtc_cmos pci_hotplug tpm_tis sg tpm pcspkr tpm_bios serio_raw button ext3 jbd mbcache uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif usb_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod
|
||||
|
||||
Pid: 16196, comm: Hibackp Not tainted 3.0.13-0.27-default #1 IBM System x3550 M3 -[7944 K3G]-/94Y7614
|
||||
RIP: 0010:[<ffffffff8103157e>] [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
|
||||
RSP: 0018:ffff88094165fe80 EFLAGS: 00010246
|
||||
RAX: 00003300ff33b000 RBX: ffff880100000000 RCX: 0000000000000000
|
||||
RDX: 0000000100000000 RSI: ffff880000000000 RDI: ff32b300ff33b400
|
||||
RBP: 0000000000001000 R08: 00003ffffffff000 R09: 0000000000000000
|
||||
R10: 22302e31223d6e6f R11: 0000000000000246 R12: 0000000000001000
|
||||
R13: 0000000000003000 R14: 0000000000571be0 R15: ffff88094165ff50
|
||||
FS: 00007ff152d33700(0000) GS:ffff88097f2c0000(0000) knlGS:0000000000000000
|
||||
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
|
||||
CR2: ffffbb00ff33b000 CR3: 00000009405a3000 CR4: 00000000000006e0
|
||||
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||||
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
|
||||
Process Hibackp (pid: 16196, threadinfo ffff88094165e000, task ffff8808eb9ba600)
|
||||
Stack:
|
||||
ffffffff811b8aaa 0000000000004000 ffff880943fea480 ffff8808ef2bae50
|
||||
ffff880943d32980 fffffffffffffffb ffff8808ef2bae40 ffff88094165ff50
|
||||
0000000000004000 000000000056ebe0 ffffffff811ad847 000000000056ebe0
|
||||
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. If reviewers agree then it
|
||||
should also be included in -stable back as far as 3.0-stable.
|
||||
|
||||
Cc: stable@vger.kernel.org
|
||||
Signed-off-by: Mel Gorman <mgorman@suse.de>
|
||||
---
|
||||
arch/x86/include/asm/pgtable.h | 5 +++++
|
||||
arch/x86/mm/init_64.c | 3 +++
|
||||
2 files changed, 8 insertions(+)
|
||||
|
||||
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
|
||||
index 5199db2..1c1a955 100644
|
||||
--- a/arch/x86/include/asm/pgtable.h
|
||||
+++ b/arch/x86/include/asm/pgtable.h
|
||||
@@ -142,6 +142,11 @@ static inline unsigned long pmd_pfn(pmd_t pmd)
|
||||
return (pmd_val(pmd) & PTE_PFN_MASK) >> PAGE_SHIFT;
|
||||
}
|
||||
|
||||
+static inline unsigned long pud_pfn(pud_t pud)
|
||||
+{
|
||||
+ return (pud_val(pud) & PTE_PFN_MASK) >> PAGE_SHIFT;
|
||||
+}
|
||||
+
|
||||
#define pte_page(pte) pfn_to_page(pte_pfn(pte))
|
||||
|
||||
static inline int pmd_large(pmd_t pte)
|
||||
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
|
||||
index 2ead3c8..75c9a6a 100644
|
||||
--- a/arch/x86/mm/init_64.c
|
||||
+++ b/arch/x86/mm/init_64.c
|
||||
@@ -831,6 +831,9 @@ int kern_addr_valid(unsigned long addr)
|
||||
if (pud_none(*pud))
|
||||
return 0;
|
||||
|
||||
+ if (pud_large(*pud))
|
||||
+ return pfn_valid(pud_pfn(*pud));
|
||||
+
|
||||
pmd = pmd_offset(pud, addr);
|
||||
if (pmd_none(*pmd))
|
||||
return 0;
|
||||
|
||||
--
|
||||
To unsubscribe, send a message with 'unsubscribe linux-mm' in
|
||||
the body to majordomo@kvack.org. For more info on Linux MM,
|
||||
see: http://www.linux-mm.org/ .
|
||||
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
|
||||
|
||||
|
|
@ -1,131 +0,0 @@
|
|||
From 13d2b4d11d69a92574a55bfd985cfb0ca77aebdc Mon Sep 17 00:00:00 2001
|
||||
From: Jan Beulich <JBeulich@suse.com>
|
||||
Date: Thu, 24 Jan 2013 13:11:10 +0000
|
||||
Subject: [PATCH] x86/xen: don't assume %ds is usable in xen_iret for 32-bit
|
||||
PVOPS.
|
||||
|
||||
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>
|
||||
---
|
||||
arch/x86/xen/xen-asm_32.S | 14 +++++++-------
|
||||
1 files changed, 7 insertions(+), 7 deletions(-)
|
||||
|
||||
diff --git a/arch/x86/xen/xen-asm_32.S b/arch/x86/xen/xen-asm_32.S
|
||||
index f9643fc..33ca6e4 100644
|
||||
--- 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
|
||||
|
||||
--
|
||||
1.7.7.6
|
||||
|
||||
Loading…
Reference in New Issue