From patchwork Mon Apr 25 19:28:42 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brad Figg X-Patchwork-Id: 92773 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 110D8B6F1B 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 1QERRO-0003E5-LY; Mon, 25 Apr 2011 19:27:26 +0000 Received: from adelie.canonical.com ([91.189.90.139]) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1QERRM-0003DE-9B for kernel-team@lists.ubuntu.com; Mon, 25 Apr 2011 19:27:24 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by adelie.canonical.com with esmtp (Exim 4.71 #1 (Debian)) id 1QERRM-00054g-3g for ; Mon, 25 Apr 2011 19:27:24 +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 1QERRL-0000qB-OS for kernel-team@lists.ubuntu.com; Mon, 25 Apr 2011 19:27:24 +0000 From: Brad Figg To: kernel-team@lists.ubuntu.com Subject: [Dapper] [CVE-2011-0695] [PATCH 1/1] IB/cm: Bump reference count on cm_id before invoking callback, CVE-2011-0695 Date: Mon, 25 Apr 2011 12:28:42 -0700 Message-Id: <1303759722-15174-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 (backported 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 02110e0..c777dbd 100644 --- a/drivers/infiniband/core/cm.c +++ b/drivers/infiniband/core/cm.c @@ -2648,6 +2648,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_irqrestore(&cm.lock, flags); cm_id_priv->id.cm_handler = cur_cm_id_priv->id.cm_handler;