linux-kernel - [PATCH 4.14 40/45] ucma: fix a use-after-free in ucma_resolve

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20181011152510.676306450@linuxfoundation.org>
Date:   Thu, 11 Oct 2018 17:40:07 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org,
        syzbot+cfe3c1e8ef634ba8964b@...kaller.appspotmail.com,
        Jason Gunthorpe <jgg@...lanox.com>,
        Doug Ledford <dledford@...hat.com>,
        Leon Romanovsky <leon@...nel.org>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Leon Romanovsky <leonro@...lanox.com>
Subject: [PATCH 4.14 40/45] ucma: fix a use-after-free in ucma_resolve_ip()

4.14-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Cong Wang <xiyou.wangcong@...il.com>

commit 5fe23f262e0548ca7f19fb79f89059a60d087d22 upstream.

There is a race condition between ucma_close() and ucma_resolve_ip():

CPU0				CPU1
ucma_resolve_ip():		ucma_close():

ctx = ucma_get_ctx(file, cmd.id);

        list_for_each_entry_safe(ctx, tmp, &file->ctx_list, list) {
                mutex_lock(&mut);
                idr_remove(&ctx_idr, ctx->id);
                mutex_unlock(&mut);
		...
                mutex_lock(&mut);
                if (!ctx->closing) {
                        mutex_unlock(&mut);
                        rdma_destroy_id(ctx->cm_id);
		...
                ucma_free_ctx(ctx);

ret = rdma_resolve_addr();
ucma_put_ctx(ctx);

Before idr_remove(), ucma_get_ctx() could still find the ctx
and after rdma_destroy_id(), rdma_resolve_addr() may still
access id_priv pointer. Also, ucma_put_ctx() may use ctx after
ucma_free_ctx() too.

ucma_close() should call ucma_put_ctx() too which tests the
refcnt and waits for the last one releasing it. The similar
pattern is already used by ucma_destroy_id().

Reported-and-tested-by: syzbot+da2591e115d57a9cbb8b@...kaller.appspotmail.com
Reported-by: syzbot+cfe3c1e8ef634ba8964b@...kaller.appspotmail.com
Cc: Jason Gunthorpe <jgg@...lanox.com>
Cc: Doug Ledford <dledford@...hat.com>
Cc: Leon Romanovsky <leon@...nel.org>
Signed-off-by: Cong Wang <xiyou.wangcong@...il.com>
Reviewed-by: Leon Romanovsky <leonro@...lanox.com>
Signed-off-by: Doug Ledford <dledford@...hat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

---
 drivers/infiniband/core/ucma.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -1742,6 +1742,8 @@ static int ucma_close(struct inode *inod
 		mutex_lock(&mut);
 		if (!ctx->closing) {
 			mutex_unlock(&mut);
+			ucma_put_ctx(ctx);
+			wait_for_completion(&ctx->comp);
 			/* rdma_destroy_id ensures that no event handlers are
 			 * inflight for that id before releasing it.
 			 */