From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sender-op-o13.zoho.eu (sender-op-o13.zoho.eu [136.143.169.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7BE8737D128 for ; Thu, 9 Jul 2026 07:23:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.169.13 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783581812; cv=pass; b=gOPkUYleOWBrpc3BTRfWYMcrfefAl1hUAkP8RP+ZFMi7sU66AZog5Vc48J9vBaNbi8zECoSX6kLFXtVf5j3EMPZKXGxZYHbm+tGfybbhi2/pjqmgWUsBX/AosLZ0H1vUvEsmT4caudKH9WA2h50ehkMBvYmP86gPZ8sRU4KgYNs= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783581812; c=relaxed/simple; bh=rYXFS9xHWuxQzCIZzhwsqpVUQPKRsFxknlyN1JD5Vos=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dCdY7VXx5HyXUuNKQu9sLcbFq9yaMLlY2VF0fcBFr7Zye4aa2/CoPvqikwhgcz7t2KwBpBIWDCsHT7rFrEll/T/ofFTuPGrupyX4bU31bj+q+kHyE5UQEtda9yJmcTe8Eg9kbYfcUruS3WHPNUgKBn+8B71B6BEz9CSieOzhj3A= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=auditcode.ai; spf=pass smtp.mailfrom=auditcode.ai; dkim=pass (1024-bit key) header.d=auditcode.ai header.i=security@auditcode.ai header.b=VIS+K0JE; arc=pass smtp.client-ip=136.143.169.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=auditcode.ai Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=auditcode.ai Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=auditcode.ai header.i=security@auditcode.ai header.b="VIS+K0JE" ARC-Seal: i=1; a=rsa-sha256; t=1783581779; cv=none; d=zohomail.eu; s=zohoarc; b=VK21chKWofYbNuJIrzzGpsRRVvHoqOi+e6wXH1BWKh4LB7/UZ7VL1cXqbSj2ObBR9WvPplyYuKKIWi29nOOi/zFerjGiiINthO4HrDtV3rY3zucH+RAQQUnhIKHPfXehqHd6036pcjjgLSuFm2hG8emUBH/tmxDTS2E0Uzx3ly8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1783581779; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=VFtLFkRLEWW8l7BwPhVXWJVcL1yGskcHu0COgJoFJaw=; b=leuhatw7b67vDhbFlfCyG2s9zDd+q6T1sQ5dVwlS5WqRKZ1N4xdFvUTO01WSjQwCGSRJQ39nEYXon12zRl6hP+9gpBiaXFW9cYMbN06YxgTYqg329Ar2zQbPntsdS2d84zjXN0ISs6pjSriBD5TYqAPnfJrIRI+j0UGWx9azpa4= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=auditcode.ai; spf=pass smtp.mailfrom=security@auditcode.ai; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1783581779; s=zmail; d=auditcode.ai; i=security@auditcode.ai; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Message-Id:Reply-To; bh=VFtLFkRLEWW8l7BwPhVXWJVcL1yGskcHu0COgJoFJaw=; b=VIS+K0JEDOAfm7QoGp134j5BPE88sBezBKc+E4lxROnWoooj+UD2INEh+yYOQ9sW 1F2h+mPbUTQsvOG95UhLo1VqURjB8FTCWLMJvvGam8NN6JjNDp1T/DHrOrsEsI+RYh+ UgPkKd/ns3XSayic4fI4YwSnyX9iPqql+7ufVcLc= Received: by mx.zoho.eu with SMTPS id 1783581778052657.1501097294694; Thu, 9 Jul 2026 09:22:58 +0200 (CEST) From: Ibrahim Hashimov To: yanjun.zhu@linux.dev, zyjzyj2000@gmail.com, jgg@ziepe.ca, leon@kernel.org Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] RDMA/rxe: fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp Date: Thu, 9 Jul 2026 09:22:53 +0200 Message-ID: <20260709072253.8918-1-security@auditcode.ai> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: <20260708224550.1281-1-security@auditcode.ai> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-ZohoMailClient: External Hi Zhu Yanjun, thanks for the review. > > BUG: KASAN: slab-use-after-free in rxe_receiver+0x4f78/0x89e0 [rdma_rxe] > > Workqueue: rxe_wq do_work [rdma_rxe] > Can you share all the stack trace with us? Thanks a lot. Sure. The read side -- the recv_task kworker running rxe_receiver() on the freed rd_atomic resource array -- from the pre-fix v6.19 kernel (CONFIG_KASAN generic, rxe loopback): BUG: KASAN: slab-use-after-free in rxe_receiver+0x4f78/0x89e0 [rdma_rxe] Read of size 4 at addr ffff88800b79f84c by task kworker/u8:2/51 CPU: 0 UID: 0 PID: 51 Comm: kworker/u8:2 Not tainted 6.19.0 #1 Workqueue: rxe_wq do_work [rdma_rxe] Call Trace: dump_stack_lvl+0x4d/0x70 print_report+0x170/0x4f3 kasan_report+0xda/0x110 rxe_receiver+0x4f78/0x89e0 [rdma_rxe] do_work+0x144/0x470 [rdma_rxe] process_one_work+0x611/0xe80 worker_thread+0x52e/0xdc0 kthread+0x30c/0x630 ret_from_fork+0x2fd/0x3e0 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff88800b79f800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 76 bytes inside of freed 1024-byte region [ffff88800b79f800, ffff88800b79fc00) The freed kmalloc-1k object is qp->resp.resources[] (the rd_atomic array); it is freed by the concurrent ib_modify_qp(IB_QP_MAX_DEST_RD_ATOMIC) thread in free_rd_atomic_resources() <- rxe_qp_from_attr(), while this recv_task kworker reads it. This was a kasan_multi_shot run and the per-object Allocated-by/Freed-by backtraces were lost in the splat storm -- I can send a single-shot capture that includes those two stacks if it would help. > If alloc_rd_atomic_resources fails, that is, qp->resp.resources is NULL. > After rxe_enable_task(&qp->recv_task); qp->resp.resources(NULL) will be > used in resp. This will cause problems. > drivers/infiniband/sw/rxe/rxe_resp.c:656: res = &qp->resp.resources[qp->resp.res_head]; > drivers/infiniband/sw/rxe/rxe_resp.c:1325: struct resp_res *res = &qp->resp.resources[i]; Good catch -- you're right. Re-enabling recv_task before the error check resumes the responder against a NULL qp->resp.resources on the ENOMEM path. v2 moves rxe_enable_task() below the error check, so the responder is re-enabled only once a fresh array has been installed and stays quiesced on failure: rxe_disable_task(&qp->recv_task); free_rd_atomic_resources(qp); err = alloc_rd_atomic_resources(qp, max_dest_rd_atomic); if (err) return err; rxe_enable_task(&qp->recv_task); rxe_disable_task()/rxe_enable_task() are state-based (TASK_STATE_DRAINED /IDLE), not refcounted, so leaving recv_task drained on the failed modify is safe and recoverable: a subsequent successful modify_qp or a QP destroy both handle the DRAINED state. I'll send this as [PATCH v2]. Thanks, Ibrahim