From: Doug Ledford <dledford@redhat.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Boris Pismenny <borisp@mellanox.com>,
stable@vger.kernel.org, security@kernel.org,
Yevgeny Kliteynik <kliteyn@mellanox.com>,
Tziporet Koren <tziporet@mellanox.com>,
Alex Polak <alexpo@mellanox.com>
Subject: Re: [PATCH security IB/uverbs: Perform validity check for supplied port number in create_ah
Date: Thu, 29 Jun 2017 12:41:58 -0400 [thread overview]
Message-ID: <1498754518.2929.1.camel@redhat.com> (raw)
In-Reply-To: <20170627120913.14963-1-leon@kernel.org>
On Tue, 2017-06-27 at 15:09 +0300, Leon Romanovsky wrote:
>
> Hi Doug and Security Team,
>
> How should we proceed with the following patch?
>
> The malicious user (non-root) can send ib_create_ah() comamnd
> to exposed /sys/class/infiniband_verbs/uverbs* file.
Your explanation is not making a lot of sense. The
/sys/class/infiniband_verbs/uverbs* files are directories, not files.
Are you saying we have an open method by which you can open the
directory in question and then send ib verbs commands over the
directory file? And even if you really mean some other file in that
directory, why would we be fixing the create_ah handler instead of
fixing the sysfs write handler for that file to not accept ib verbs
commands? Why would we be talking ib verbs commands on *any* sysfs
file?
> All that is
> needed is to provide port number which is out-of-range and it will
> kill the system.
Why is this not an issue on the normal /dev/infiniband/uverbs* files
(which are world writable)? Is that merely because rdma-
core/libibverbs checks the port number before submitting the command?
If so, then a maliciously changed rdma-core/libibverbs would have the
same problem.
> There is need to be root to open uverbs* file, but after that those
> persmissions can be dropped.
I don't get the issue with the sysfs file, but the bug appears to be
exploitable by any user who is willing to recompile rdma-core to bypass
any checks it might have on input validity. From what I can tell, the
offending code that should be the source of the problem is
rdma_ah_find_type() which uses the user supplied port_num for an array
lookup without checking it for validity, thereby being tricked into
going outside the array bounds by user input. We call
rdma_ah_find_type() in two locations: ib_verbs.c:modify_qp() and
ib_verbs.c:ib_uverbs_create_ah(). Why is this a bug in one and not the
other? And in modify_qp() it looks like we actually use cmd-
>base.port_num, cmd->base.alt_port_num, and cmd->base.dest.port_num,
all as user provided values without checking.
> Thanks
> ---
> drivers/infiniband/core/uverbs_cmd.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/infiniband/core/uverbs_cmd.c
> b/drivers/infiniband/core/uverbs_cmd.c
> index 70b7fb156414..6065395b6465 100644
> --- a/drivers/infiniband/core/uverbs_cmd.c
> +++ b/drivers/infiniband/core/uverbs_cmd.c
> @@ -2541,6 +2541,9 @@ ssize_t ib_uverbs_create_ah(struct
> ib_uverbs_file *file,
> if (copy_from_user(&cmd, buf, sizeof cmd))
> return -EFAULT;
>
> + if (!rdma_is_port_valid(ib_dev, cmd.attr.port_num))
> + return -EINVAL;
> +
> INIT_UDATA(&udata, buf + sizeof(cmd),
> (unsigned long)cmd.response + sizeof(resp),
> in_len - sizeof(cmd), out_len - sizeof(resp));
> --
> 2.13.1
>
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
next prev parent reply other threads:[~2017-06-29 16:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-27 12:09 [PATCH security IB/uverbs: Perform validity check for supplied port number in create_ah Leon Romanovsky
2017-06-29 16:41 ` Doug Ledford [this message]
2017-06-29 18:16 ` Leon Romanovsky
2017-06-29 18:30 ` Linus Torvalds
2017-06-29 18:40 ` Leon Romanovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1498754518.2929.1.camel@redhat.com \
--to=dledford@redhat.com \
--cc=alexpo@mellanox.com \
--cc=borisp@mellanox.com \
--cc=kliteyn@mellanox.com \
--cc=leon@kernel.org \
--cc=security@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tziporet@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.