[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1427969085.17020.5.camel@opteya.com>
Date: Thu, 02 Apr 2015 12:04:45 +0200
From: Yann Droneaud <ydroneaud@...eya.com>
To: Shachar Raindel <raindel@...lanox.com>
Cc: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>,
"<linux-rdma@...r.kernel.org> (linux-rdma@...r.kernel.org)"
<linux-rdma@...r.kernel.org>, linux-kernel@...r.kernel.org,
"stable@...r.kernel.org"
<stable@...r.kernel.org>
Subject: Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical
memory access
Hi,
Le mercredi 18 mars 2015 à 17:39 +0000, Shachar Raindel a écrit :
> Hi,
>
> It was found that the Linux kernel's InfiniBand/RDMA subsystem did not
> properly sanitize input parameters while registering memory regions
> from user space via the (u)verbs API. A local user with access to
> a /dev/infiniband/uverbsX device could use this flaw to crash the
> system or, potentially, escalate their privileges on the system.
>
> The issue has been assigned CVE-2014-8159.
>
> The issue exists in the InfiniBand/RDMA/iWARP drivers since Linux
> Kernel version 2.6.13.
>
> Mellanox OFED 2.4-1.0.4 fixes the issue. Available from:
> http://www.mellanox.com/page/products_dyn?product_family=26&mtag=linux_sw_drivers
>
> RedHat errata: https://access.redhat.com/security/cve/CVE-2014-8159
> Canonical errata: http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-8159.html
> Novell (Suse) bug tracking: https://bugzilla.novell.com/show_bug.cgi?id=914742
>
>
> The following patch fixes the issue:
>
> --------------- 8< ------------------------------
>
> From d4d68430d4a12c569e28b4f4468284ea22111186 Mon Sep 17 00:00:00 2001
> From: Shachar Raindel <raindel@...lanox.com>
> Date: Sun, 04 Jan 2015 18:30:32 +0200
> Subject: [PATCH] IB/core: Prevent integer overflow in ib_umem_get address arithmetic
>
> Properly verify that the resulting page aligned end address is larger
> than both the start address and the length of the memory area
> requested.
>
> Both the start and length arguments for ib_umem_get are controlled by
> the user. A misbehaving user can provide values which will cause an
> integer overflow when calculating the page aligned end address.
>
> This overflow can cause also miscalculation of the number of pages
> mapped, and additional logic issues.
>
> Signed-off-by: Shachar Raindel <raindel@...lanox.com>
> Signed-off-by: Jack Morgenstein <jackm@...lanox.com>
> Signed-off-by: Or Gerlitz <ogerlitz@...lanox.com>
> ---
>
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index aec7a6a..8c014b5 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -99,6 +99,14 @@
> if (dmasync)
> dma_set_attr(DMA_ATTR_WRITE_BARRIER, &attrs);
>
> + /*
> + * If the combination of the addr and size requested for this memory
> + * region causes an integer overflow, return error.
> + */
> + if ((PAGE_ALIGN(addr + size) <= size) ||
> + (PAGE_ALIGN(addr + size) <= addr))
> + return ERR_PTR(-EINVAL);
> +
Can access_ok() be used here ?
if (!access_ok(writable ? VERIFY_WRITE : VERIFY_READ,
addr, size))
return ERR_PTR(-EINVAL);
> if (!can_do_mlock())
> return ERR_PTR(-EPERM);
>
Regards.
--
Yann Droneaud
OPTEYA
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
