rpms
/
kernel
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Linux v4.5.3

This commit is contained in:
Justin M. Forbes 2016-05-04 20:24:32 -05:00
parent d5b1540844
commit 4d81848a2b
7 changed files with 6 additions and 306 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
0001-ARM-mvebu-Correct-unit-address-for-linksys.patch
View File

@ -1,32 +0,0 @@
From 0eebfe3b5ae99d3a825be8e45395cea478fd83d8 Mon Sep 17 00:00:00 2001
From: Patrick Uiterwijk <patrick@puiterwijk.org>
Date: Mon, 28 Mar 2016 21:30:41 +0000
Subject: [PATCH] ARM: mvebu: Correct unit address for linksys
The USB2 port for Armada 38x is defined to be at 58000, not at
50000.
Acked-by: Imre Kaloz <kaloz@openwrt.org>
Cc: <stable@vger.kernel.org>
Fixes: 2d0a7addbd10 ("ARM: Kirkwood: Add support for many Synology NAS devices")
Signed-off-by: Patrick Uiterwijk <patrick@puiterwijk.org>
---
arch/arm/boot/dts/armada-385-linksys.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi b/arch/arm/boot/dts/armada-385-linksys.dtsi
index 3710755..85d2c37 100644
--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
@@ -117,7 +117,7 @@
};
/* USB part of the eSATA/USB 2.0 port */
- usb@50000 {
+ usb@58000 {
status = "okay";
};
--
2.5.0

45
USB-usbip-fix-potential-out-of-bounds-write.patch
View File

@ -1,45 +0,0 @@
From b348d7dddb6c4fbfc810b7a0626e8ec9e29f7cbb Mon Sep 17 00:00:00 2001
From: Ignat Korchagin <ignat.korchagin@gmail.com>
Date: Thu, 17 Mar 2016 18:00:29 +0000
Subject: [PATCH] USB: usbip: fix potential out-of-bounds write
Fix potential out-of-bounds write to urb->transfer_buffer
usbip handles network communication directly in the kernel. When receiving a
packet from its peer, usbip code parses headers according to protocol. As
part of this parsing urb->actual_length is filled. Since the input for
urb->actual_length comes from the network, it should be treated as untrusted.
Any entity controlling the network may put any value in the input and the
preallocated urb->transfer_buffer may not be large enough to hold the data.
Thus, the malicious entity is able to write arbitrary data to kernel memory.
Signed-off-by: Ignat Korchagin <ignat.korchagin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/usbip/usbip_common.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/usbip/usbip_common.c b/drivers/usb/usbip/usbip_common.c
index facaaf003f19..e40da7759a0e 100644
--- a/drivers/usb/usbip/usbip_common.c
+++ b/drivers/usb/usbip/usbip_common.c
@@ -741,6 +741,17 @@ int usbip_recv_xbuff(struct usbip_device *ud, struct urb *urb)
if (!(size > 0))
return 0;
+ if (size > urb->transfer_buffer_length) {
+ /* should not happen, probably malicious packet */
+ if (ud->side == USBIP_STUB) {
+ usbip_event_add(ud, SDEV_EVENT_ERROR_TCP);
+ return 0;
+ } else {
+ usbip_event_add(ud, VDEV_EVENT_ERROR_TCP);
+ return -EPIPE;
+ }
+ }
+
ret = usbip_recv(ud->tcp_socket, urb->transfer_buffer, size);
if (ret != size) {
dev_err(&urb->dev->dev, "recv xbuf, %d\n", ret);
--
2.5.5

92
efi-arm64-don-t-apply-MEMBLOCK_NOMAP-to-UEFI-memory-map-mapping.patch
View File

@ -1,92 +0,0 @@
From patchwork Wed Mar 30 07:46:23 2016
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: efi/arm64: don't apply MEMBLOCK_NOMAP to UEFI memory map mapping
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
X-Patchwork-Id: 8693271
Message-Id: <1459323983-9120-1-git-send-email-ard.biesheuvel@linaro.org>
To: linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
matt@codeblueprint.co.uk
Cc: mark.rutland@arm.com, mlangsdo@redhat.com,
Ard Biesheuvel <ard.biesheuvel@linaro.org>, leif.lindholm@linaro.org,
jeremy.linton@arm.com, msalter@redhat.com
Date: Wed, 30 Mar 2016 09:46:23 +0200
Hi Matt,
Could we queue this as a fix for v4.6 with a cc:stable for v4.5, please?
(assuming no objections from any of the cc'ees)
Thanks,
Ard.
----------8<--------------
Commit 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as
MEMBLOCK_NOMAP") updated the mapping logic of both the RuntimeServices
regions as well as the kernel's copy of the UEFI memory map to set the
MEMBLOCK_NOMAP flag, which causes these regions to be omitted from the
kernel direct mapping, and from being covered by a struct page.
For the RuntimeServices regions, this is an obvious win, since the contents
of these regions have significance to the firmware executable code itself,
and are mapped in the EFI page tables using attributes that are described in
the UEFI memory map, and which may differ from the attributes we use for
mapping system RAM. It also prevents the contents from being modified
inadvertently, since the EFI page tables are only live during runtime
service invocations.
None of these concerns apply to the allocation that covers the UEFI memory
map, since it is entirely owned by the kernel. Setting the MEMBLOCK_NOMAP on
the region did allow us to use ioremap_cache() to map it both on arm64 and
on ARM, since the latter does not allow ioremap_cache() to be used on
regions that are covered by a struct page.
The ioremap_cache() on ARM restriction will be lifted in the v4.7 timeframe,
but in the mean time, it has been reported that commit 4dffbfc48d65 causes
a regression on 64k granule kernels. This is due to the fact that, given
the 64 KB page size, the region that we end up removing from the kernel
direct mapping is rounded up to 64 KB, and this 64 KB page frame may be
shared with the initrd when booting via GRUB (which does not align its
EFI_LOADER_DATA allocations to 64 KB like the stub does). This will crash
the kernel as soon as it tries to access the initrd.
Since the issue is specific to arm64, revert back to memblock_reserve()'ing
the UEFI memory map when running on arm64. This is a temporary fix for v4.5
and v4.6, and will be superseded in the v4.7 timeframe when we will be able
to move back to memblock_reserve() unconditionally.
Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP")
Reported-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/arm-init.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index aa1f743152a2..8714f8c271ba 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -203,7 +203,19 @@ void __init efi_init(void)
reserve_regions();
early_memunmap(memmap.map, params.mmap_size);
- memblock_mark_nomap(params.mmap & PAGE_MASK,
- PAGE_ALIGN(params.mmap_size +
- (params.mmap & ~PAGE_MASK)));
+
+ if (IS_ENABLED(CONFIG_ARM)) {
+ /*
+ * ARM currently does not allow ioremap_cache() to be called on
+ * memory regions that are covered by struct page. So remove the
+ * UEFI memory map from the linear mapping.
+ */
+ memblock_mark_nomap(params.mmap & PAGE_MASK,
+ PAGE_ALIGN(params.mmap_size +
+ (params.mmap & ~PAGE_MASK)));
+ } else {
+ memblock_reserve(params.mmap & PAGE_MASK,
+ PAGE_ALIGN(params.mmap_size +
+ (params.mmap & ~PAGE_MASK)));
+ }
}

49
input-gtco-fix-crash-on-detecting-device-without-end.patch
View File

@ -1,49 +0,0 @@
Subject: [PATCH] Input: gtco: fix crash on detecting device without endpoints
From: Vladis Dronov <vdronov@redhat.com>
Date: 2016-03-18 18:35:00
The gtco driver expects at least one valid endpoint. If given
malicious descriptors that specify 0 for the number of endpoints,
it will crash in the probe function. Ensure there is at least
one endpoint on the interface before using it. Fix minor coding
style issue.
The full report of this issue can be found here:
http://seclists.org/bugtraq/2016/Mar/86
Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
---
drivers/input/tablet/gtco.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c
index 3a7f3a4..7c18249 100644
--- a/drivers/input/tablet/gtco.c
+++ b/drivers/input/tablet/gtco.c
@@ -858,6 +858,14 @@ static int gtco_probe(struct usb_interface *usbinterface,
goto err_free_buf;
}
+ /* Sanity check that a device has an endpoint */
+ if (usbinterface->altsetting[0].desc.bNumEndpoints < 1) {
+ dev_err(&usbinterface->dev,
+ "Invalid number of endpoints\n");
+ error = -EINVAL;
+ goto err_free_urb;
+ }
+
/*
* The endpoint is always altsetting 0, we know this since we know
* this device only has one interrupt endpoint
@@ -879,7 +887,7 @@ static int gtco_probe(struct usb_interface *usbinterface,
* HID report descriptor
*/
if (usb_get_extra_descriptor(usbinterface->cur_altsetting,
- HID_DEVICE_TYPE, &hid_desc) != 0){
+ HID_DEVICE_TYPE, &hid_desc) != 0) {
dev_err(&usbinterface->dev,
"Can't retrieve exta USB descriptor to get hid report descriptor length\n");
error = -EIO;
--
2.5.0

22
kernel.spec
View File

@ -42,7 +42,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 302
%global baserelease 300
%global fedora_build %{baserelease}
# base_sublevel is the kernel version we're starting with and patching
@ -54,7 +54,7 @@ Summary: The Linux kernel
%if 0%{?released_kernel}
# Do we have a -stable update to apply?
%define stable_update 2
%define stable_update 3
# Set rpm version accordingly
%if 0%{?stable_update}
%define stablerev %{stable_update}
@ -506,9 +506,6 @@ Patch422: geekbox-v4-device-tree-support.patch
# http://www.spinics.net/lists/arm-kernel/msg483898.html
Patch423: Initial-AllWinner-A64-and-PINE64-support.patch
# http://www.spinics.net/lists/arm-kernel/msg493431.html
Patch424: efi-arm64-don-t-apply-MEMBLOCK_NOMAP-to-UEFI-memory-map-mapping.patch
# rhbz 1321330 http://www.spinics.net/lists/dri-devel/msg105829.html
Patch425: 0001-gpu-ipu-v3-Fix-imx-ipuv3-crtc-module-autoloading.patch
@ -531,9 +528,6 @@ Patch435: stmmac-fix-MDIO-settings.patch
Patch436: ARM-mvebu-change-order-of-ethernet-DT-nodes-on-Armada-38x.patch
# mvebu usb fixes http://www.spinics.net/lists/arm-kernel/msg493305.html
Patch437: 0001-ARM-mvebu-Correct-unit-address-for-linksys.patch
# mvebu DSA switch fixes
# http://www.spinics.net/lists/netdev/msg370841.html http://www.spinics.net/lists/netdev/msg370842.html
Patch438: 0001-net-dsa-mv88e6xxx-Introduce-_mv88e6xxx_phy_page_-rea.patch
@ -635,21 +629,12 @@ Patch664: netfilter-x_tables-check-for-size-overflow.patch
#CVE-2016-3134 rhbz 1317383 1317384
Patch665: netfilter-x_tables-deal-with-bogus-nextoffset-values.patch
#CVE-2016-2187 rhbz 1317017 1317010
Patch686: input-gtco-fix-crash-on-detecting-device-without-end.patch
# CVE-2016-3672 rhbz 1324749 1324750
Patch689: x86-mm-32-Enable-full-randomization-on-i386-and-X86_.patch
#rhbz 1309980
Patch698: 0001-ACPI-processor-Request-native-thermal-interrupt-hand.patch
# CVE-2016-3961 rhbz 1327219 1323956
Patch699: x86-xen-suppress-hugetlbfs-in-PV-guests.patch
# CVE-2016-3955 rhbz 1328478 1328479
Patch700: USB-usbip-fix-potential-out-of-bounds-write.patch
#rhbz 1309487
Patch701: antenna_select.patch
@ -2189,6 +2174,9 @@ fi
#
#
%changelog
* Wed May 04 2016 Justin M. Forbes <jforbes@fedoraproject.org> - 4.5.3-300
- Linux v4.5.3
* Wed May 04 2016 Josh Boyer <jwboyer@fedoraproject.org>
- Enable NFC_NXP_NCI options (rhbz 1290556)
- CVE-2016-4482 info leak in devio.c (rhbz 1332931 1332932)

2
sources
View File

@ -1,3 +1,3 @@
a60d48eee08ec0536d5efb17ca819aef linux-4.5.tar.xz
6f557fe90b800b615c85c2ca04da6154 perf-man-4.5.tar.gz
19a835c1d16183f629d45779f62d36b6 patch-4.5.2.xz
efc81327bd2bd0d946f057ac71cbb1a7 patch-4.5.3.xz

70
x86-xen-suppress-hugetlbfs-in-PV-guests.patch
View File

@ -1,70 +0,0 @@
From 72c339e0c6d9969e664c2cf63e162753d7d859ae Mon Sep 17 00:00:00 2001
From: Jan Beulich <jbeulich@suse.com>
Date: Thu, 14 Apr 2016 13:03:47 +0000
Subject: [PATCH] x86/xen: suppress hugetlbfs in PV guests
Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:
kernel BUG at .../fs/hugetlbfs/inode.c:428!
invalid opcode: 0000 [#1] SMP
Modules linked in: ...
Supported: Yes
CPU: 2 PID: 6088 Comm: hugetlbfs Tainted: G W 4.4.0-2016-01-20-pv #2
Hardware name: ...
task: ffff8808059205c0 ti: ffff880803c84000 task.ti: ffff880803c84000
RIP: e030:[<ffffffff811c333b>] [<ffffffff811c333b>] remove_inode_hugepages+0x25b/0x320
RSP: e02b:ffff880803c879a8 EFLAGS: 00010202
RAX: 000000000077a4db RBX: ffffea001acff000 RCX: 0000000078417d38
RDX: 0000000000000000 RSI: 000000007e154fa7 RDI: ffff880805d70960
RBP: 0000000000000960 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: ffff880807486018 R14: 0000000000000000 R15: ffff880803c87af0
FS: 00007f85fa8b8700(0000) GS:ffff88080b640000(0000) knlGS:0000000000000000
CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f85fa000000 CR3: 0000000001a0a000 CR4: 0000000000040660
Stack:
ffff880000000fb0 ffff880803c87a18 ffff880803c87ae8 ffff8808059205c0
ffff880803c87af0 ffff880803c87ae8 ffff880807486018 0000000000000000
ffffffff81bf6e60 ffff880807486168 000003ffffffffff 0000000003c87758
Call Trace:
[<ffffffff811c3415>] hugetlbfs_evict_inode+0x15/0x40
[<ffffffff81167b3d>] evict+0xbd/0x1b0
[<ffffffff8116514a>] __dentry_kill+0x19a/0x1f0
[<ffffffff81165b0e>] dput+0x1fe/0x220
[<ffffffff81150535>] __fput+0x155/0x200
[<ffffffff81079fc0>] task_work_run+0x60/0xa0
[<ffffffff81063510>] do_exit+0x160/0x400
[<ffffffff810637eb>] do_group_exit+0x3b/0xa0
[<ffffffff8106e8bd>] get_signal+0x1ed/0x470
[<ffffffff8100f854>] do_signal+0x14/0x110
[<ffffffff810030e9>] prepare_exit_to_usermode+0xe9/0xf0
[<ffffffff814178a5>] retint_user+0x8/0x13
This is XSA-174.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: stable@vger.kernel.org
---
arch/x86/include/asm/hugetlb.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetlb.h
index f8a29d2c97b0..e6a8613fbfb0 100644
--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -4,6 +4,7 @@
#include <asm/page.h>
#include <asm-generic/hugetlb.h>
+#define hugepages_supported() cpu_has_pse
static inline int is_hugepage_only_range(struct mm_struct *mm,
unsigned long addr,
--
2.5.5