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

Linux v4.13.8

This commit is contained in:
Laura Abbott 2017-10-18 08:02:10 -07:00
parent 3118e0a1c8
commit ab11b77a1c
4 changed files with 5 additions and 195 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

140
0001-ALSA-seq-Fix-use-after-free-at-creating-a-port.patch
View File

@ -1,140 +0,0 @@
From 71105998845fb012937332fe2e806d443c09e026 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai@suse.de>
Date: Mon, 9 Oct 2017 11:09:20 +0200
Subject: [PATCH] ALSA: seq: Fix use-after-free at creating a port
There is a potential race window opened at creating and deleting a
port via ioctl, as spotted by fuzzing. snd_seq_create_port() creates
a port object and returns its pointer, but it doesn't take the
refcount, thus it can be deleted immediately by another thread.
Meanwhile, snd_seq_ioctl_create_port() still calls the function
snd_seq_system_client_ev_port_start() with the created port object
that is being deleted, and this triggers use-after-free like:
BUG: KASAN: use-after-free in snd_seq_ioctl_create_port+0x504/0x630 [snd_seq] at addr ffff8801f2241cb1
=============================================================================
BUG kmalloc-512 (Tainted: G B ): kasan: bad access detected
-----------------------------------------------------------------------------
INFO: Allocated in snd_seq_create_port+0x94/0x9b0 [snd_seq] age=1 cpu=3 pid=4511
___slab_alloc+0x425/0x460
__slab_alloc+0x20/0x40
kmem_cache_alloc_trace+0x150/0x190
snd_seq_create_port+0x94/0x9b0 [snd_seq]
snd_seq_ioctl_create_port+0xd1/0x630 [snd_seq]
snd_seq_do_ioctl+0x11c/0x190 [snd_seq]
snd_seq_ioctl+0x40/0x80 [snd_seq]
do_vfs_ioctl+0x54b/0xda0
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x16/0x75
INFO: Freed in port_delete+0x136/0x1a0 [snd_seq] age=1 cpu=2 pid=4717
__slab_free+0x204/0x310
kfree+0x15f/0x180
port_delete+0x136/0x1a0 [snd_seq]
snd_seq_delete_port+0x235/0x350 [snd_seq]
snd_seq_ioctl_delete_port+0xc8/0x180 [snd_seq]
snd_seq_do_ioctl+0x11c/0x190 [snd_seq]
snd_seq_ioctl+0x40/0x80 [snd_seq]
do_vfs_ioctl+0x54b/0xda0
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x16/0x75
Call Trace:
[<ffffffff81b03781>] dump_stack+0x63/0x82
[<ffffffff81531b3b>] print_trailer+0xfb/0x160
[<ffffffff81536db4>] object_err+0x34/0x40
[<ffffffff815392d3>] kasan_report.part.2+0x223/0x520
[<ffffffffa07aadf4>] ? snd_seq_ioctl_create_port+0x504/0x630 [snd_seq]
[<ffffffff815395fe>] __asan_report_load1_noabort+0x2e/0x30
[<ffffffffa07aadf4>] snd_seq_ioctl_create_port+0x504/0x630 [snd_seq]
[<ffffffffa07aa8f0>] ? snd_seq_ioctl_delete_port+0x180/0x180 [snd_seq]
[<ffffffff8136be50>] ? taskstats_exit+0xbc0/0xbc0
[<ffffffffa07abc5c>] snd_seq_do_ioctl+0x11c/0x190 [snd_seq]
[<ffffffffa07abd10>] snd_seq_ioctl+0x40/0x80 [snd_seq]
[<ffffffff8136d433>] ? acct_account_cputime+0x63/0x80
[<ffffffff815b515b>] do_vfs_ioctl+0x54b/0xda0
.....
We may fix this in a few different ways, and in this patch, it's fixed
simply by taking the refcount properly at snd_seq_create_port() and
letting the caller unref the object after use. Also, there is another
potential use-after-free by sprintf() call in snd_seq_create_port(),
and this is moved inside the lock.
This fix covers CVE-2017-15265.
Reported-and-tested-by: Michael23 Yu <ycqzsy@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
sound/core/seq/seq_clientmgr.c | 6 +++++-
sound/core/seq/seq_ports.c | 7 +++++--
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
index ea2d0ae85bd3..6c9cba2166d9 100644
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -1259,6 +1259,7 @@ static int snd_seq_ioctl_create_port(struct snd_seq_client *client, void *arg)
struct snd_seq_port_info *info = arg;
struct snd_seq_client_port *port;
struct snd_seq_port_callback *callback;
+ int port_idx;
/* it is not allowed to create the port for an another client */
if (info->addr.client != client->number)
@@ -1269,7 +1270,9 @@ static int snd_seq_ioctl_create_port(struct snd_seq_client *client, void *arg)
return -ENOMEM;
if (client->type == USER_CLIENT && info->kernel) {
- snd_seq_delete_port(client, port->addr.port);
+ port_idx = port->addr.port;
+ snd_seq_port_unlock(port);
+ snd_seq_delete_port(client, port_idx);
return -EINVAL;
}
if (client->type == KERNEL_CLIENT) {
@@ -1290,6 +1293,7 @@ static int snd_seq_ioctl_create_port(struct snd_seq_client *client, void *arg)
snd_seq_set_port_info(port, info);
snd_seq_system_client_ev_port_start(port->addr.client, port->addr.port);
+ snd_seq_port_unlock(port);
return 0;
}
diff --git a/sound/core/seq/seq_ports.c b/sound/core/seq/seq_ports.c
index 0a7020c82bfc..d21ece9f8d73 100644
--- a/sound/core/seq/seq_ports.c
+++ b/sound/core/seq/seq_ports.c
@@ -122,7 +122,9 @@ static void port_subs_info_init(struct snd_seq_port_subs_info *grp)
}
-/* create a port, port number is returned (-1 on failure) */
+/* create a port, port number is returned (-1 on failure);
+ * the caller needs to unref the port via snd_seq_port_unlock() appropriately
+ */
struct snd_seq_client_port *snd_seq_create_port(struct snd_seq_client *client,
int port)
{
@@ -151,6 +153,7 @@ struct snd_seq_client_port *snd_seq_create_port(struct snd_seq_client *client,
snd_use_lock_init(&new_port->use_lock);
port_subs_info_init(&new_port->c_src);
port_subs_info_init(&new_port->c_dest);
+ snd_use_lock_use(&new_port->use_lock);
num = port >= 0 ? port : 0;
mutex_lock(&client->ports_mutex);
@@ -165,9 +168,9 @@ struct snd_seq_client_port *snd_seq_create_port(struct snd_seq_client *client,
list_add_tail(&new_port->list, &p->list);
client->num_ports++;
new_port->addr.port = num; /* store the port number in the port */
+ sprintf(new_port->name, "port-%d", num);
write_unlock_irqrestore(&client->ports_lock, flags);
mutex_unlock(&client->ports_mutex);
- sprintf(new_port->name, "port-%d", num);
return new_port;
}
--
2.13.5

11
kernel.spec
View File

@ -54,7 +54,7 @@ Summary: The Linux kernel
%if 0%{?released_kernel}
# Do we have a -stable update to apply?
%define stable_update 7
%define stable_update 8
# Set rpm version accordingly
%if 0%{?stable_update}
%define stablerev %{stable_update}
@ -588,9 +588,6 @@ Patch304: ARM-tegra-usb-no-reset.patch
Patch305: allwinner-net-emac.patch
# https://patchwork.kernel.org/patch/9967397/
Patch306: tegra-Use-different-MSI-target-address-for-Tegra20.patch
# https://www.spinics.net/lists/arm-kernel/msg554183.html
Patch307: arm-imx6-hummingboard2.patch
@ -695,9 +692,6 @@ Patch630: Input-synaptics---Disable-kernel-tracking-on-SMBus-devices.patch
# Headed upstream
Patch631: drm-i915-boost-GPU-clocks-if-we-miss-the-pageflip.patch
# CVE-2017-15265 rhbz 1501878 1501880
Patch633: 0001-ALSA-seq-Fix-use-after-free-at-creating-a-port.patch
# END OF PATCH DEFINITIONS
%endif
@ -2272,6 +2266,9 @@ fi
#
#
%changelog
* Wed Oct 18 2017 Laura Abbott <labbott@fedoraproject.org> - 4.13.8-200
- Linux v4.13.8
* Mon Oct 16 2017 Justin M. Forbes <jforbes@fedoraproject.org> - 4.13.7-200
- Linux v4.13.7
- Fixes CVE-2017-5123 (rhbz 1500094 1501762)

2
sources
View File

@ -1,3 +1,3 @@
SHA512 (linux-4.13.tar.xz) = a557c2f0303ae618910b7106ff63d9978afddf470f03cb72aa748213e099a0ecd5f3119aea6cbd7b61df30ca6ef3ec57044d524b7babbaabddf8b08b8bafa7d2
SHA512 (perf-man-4.13.tar.gz) = 9bcc2cd8e56ec583ed2d8e0b0c88e7a94035a1915e40b3177bb02d6c0f10ddd4df9b097b1f5af59efc624226b613e240ddba8ddc2156f3682f992d5455fc5c03
SHA512 (patch-4.13.7.xz) = 4d96c655ca4c720b872e1a88ba9989a419880cb5fec2a4a9190077588066f205c5dce2591a76f26375f6f50001334ceb7631d489d3b24ca443d10e1e6879ed54
SHA512 (patch-4.13.8.xz) = b70b1a081155fa9a7082ad2771aa0a43a9f6458aa5f7f312729aaa3a71db71d28bcd1d1cac6ffaee134797359f37ee86de70537c1190ca60c016a8779268e880

47
tegra-Use-different-MSI-target-address-for-Tegra20.patch
View File

@ -1,47 +0,0 @@
From patchwork Sat Sep 23 06:17:40 2017
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: PCI: tegra: Use different MSI target address for Tegra20
From: Thierry Reding <thierry.reding@gmail.com>
X-Patchwork-Id: 9967397
Message-Id: <20170923061740.6012-1-treding@nvidia.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
linux-pci@vger.kernel.org, linux-tegra@vger.kernel.org
Date: Fri, 22 Sep 2017 23:17:40 -0700
The Tegra20 PCIe controller has a different address range for MSI, so
select a different target address.
Fixes: d7bd554f27c9 ("PCI: tegra: Do not allocate MSI target memory")
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/pci/host/pci-tegra.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index e8e1ddbaabc9..5b02ea59524b 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -1563,8 +1563,18 @@ static int tegra_pcie_enable_msi(struct tegra_pcie *pcie)
* none of the Tegra SoCs that contain this PCI host bridge can
* address more than 16 GiB of system memory, the last 4 KiB of
* these 1012 GiB is a good candidate.
+ *
+ * Unfortunately, Tegra20 is slightly different in that the physical
+ * address for this MSI region is limited to the lower 32 bits of the
+ * address map, so the address that we pick is going to have to be
+ * located somewhere within the region addressable by the CPU and
+ * on-SoC controllers. To be on the safe side, we select an address
+ * from a region that is marked unused (0xf0010000 - 0xfffeffff).
*/
- msi->phys = 0xfcfffff000;
+ if (soc->msi_base_shift > 0)
+ msi->phys = 0xfcfffff000;
+ else
+ msi->phys = 0x00f0010000;
afi_writel(pcie, msi->phys >> soc->msi_base_shift, AFI_MSI_FPCI_BAR_ST);
afi_writel(pcie, msi->phys, AFI_MSI_AXI_BAR_ST);