From patchwork Mon Apr 25 19:28:47 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brad Figg X-Patchwork-Id: 92772 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from chlorine.canonical.com (chlorine.canonical.com [91.189.94.204]) by ozlabs.org (Postfix) with ESMTP id 110A5B6F19 for ; Tue, 26 Apr 2011 05:27:39 +1000 (EST) Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1QERRT-0003Eo-H6; Mon, 25 Apr 2011 19:27:31 +0000 Received: from adelie.canonical.com ([91.189.90.139]) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1QERRR-0003EU-W1 for kernel-team@lists.ubuntu.com; Mon, 25 Apr 2011 19:27:30 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by adelie.canonical.com with esmtp (Exim 4.71 #1 (Debian)) id 1QERRR-00059k-Up for ; Mon, 25 Apr 2011 19:27:29 +0000 Received: from static-50-53-98-161.bvtn.or.frontiernet.net ([50.53.98.161] helo=localhost) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1QERRR-0000qc-JO for kernel-team@lists.ubuntu.com; Mon, 25 Apr 2011 19:27:29 +0000 From: Brad Figg To: kernel-team@lists.ubuntu.com Subject: [Hardy] [CVE-2011-0695] [PATCH 1/2] IB/cm: Bump reference count on cm_id before invoking callback, CVE-2011-0695 Date: Mon, 25 Apr 2011 12:28:47 -0700 Message-Id: <1303759728-15256-1-git-send-email-brad.figg@canonical.com> X-Mailer: git-send-email 1.7.0.4 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.13 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: kernel-team-bounces@lists.ubuntu.com Errors-To: kernel-team-bounces@lists.ubuntu.com From: Sean Hefty CVE-2011-0695 BugLink: http://bugs.launchpad.net/bugs/770369 When processing a SIDR REQ, the ib_cm allocates a new cm_id. The refcount of the cm_id is initialized to 1. However, cm_process_work will decrement the refcount after invoking all callbacks. The result is that the cm_id will end up with refcount set to 0 by the end of the sidr req handler. If a user tries to destroy the cm_id, the destruction will proceed, under the incorrect assumption that no other threads are referencing the cm_id. This can lead to a crash when the cm callback thread tries to access the cm_id. This problem was noticed as part of a larger investigation with kernel crashes in the rdma_cm when running on a real time OS. Signed-off-by: Sean Hefty Acked-by: Doug Ledford Cc: Signed-off-by: Roland Dreier (cherry-picked from commit 29963437a48475036353b95ab142bf199adb909e) Signed-off-by: Brad Figg Acked-by: Tim Gardner Acked-by: Leann Ogasawara --- drivers/infiniband/core/cm.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c index 64e0903..1d9616b 100644 --- a/drivers/infiniband/core/cm.c +++ b/drivers/infiniband/core/cm.c @@ -2989,6 +2989,7 @@ static int cm_sidr_req_handler(struct cm_work *work) goto out; /* No match. */ } atomic_inc(&cur_cm_id_priv->refcount); + atomic_inc(&cm_id_priv->refcount); spin_unlock_irq(&cm.lock); cm_id_priv->id.cm_handler = cur_cm_id_priv->id.cm_handler;