From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 01E08C43458 for ; Wed, 1 Jul 2026 20:29:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Reply-To:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: References:In-Reply-To:Cc:To:Subject:From:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0m8JkTNYeiDgi/V3quiAscvE/YDKRZACu8OyehqvlDk=; b=xWVoKOvbyztUjG 5XSqIaBbHbpXhKNXrB2RH8/LJcbOqH3ZS80AoDvgJV3PFGrzlDjW8HamU5N7xkvBhxEYraKOvJqui 5ieFWlAXHKD+zzqLyTaTSwGLOzJp8kX1qQKQtzUxjtJ1U0Uycc48i+oaxkQoVIo0nGCq7WUOJXT+B AkklstUXiDAHUfPuAS1wd5N15HUgd25ns5QYgei/RJjBHu31xPPpIgjbg5Ka7JP36iTJxkNjf8JWS n4Doypskvudc71Tu3w1tQJyQGllBuxkNAUCoyil6UyNsOcwkqWfkpr/t/CnyqYY2PnWFzETMvfZgJ TFyt2UNiQkYa2ytQsUsQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wf1YT-00000002y05-37v5; Wed, 01 Jul 2026 20:29:09 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wf1YS-00000002xzw-1WZ6 for linux-i3c@lists.infradead.org; Wed, 01 Jul 2026 20:29:08 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id DC6E343F5E; Wed, 1 Jul 2026 20:29:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 779531F000E9; Wed, 1 Jul 2026 20:29:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782937745; bh=Dr+I3p8ZIjxW6pp0wwweggYhAj35PUYgw3Cl0InNCvo=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=n3tLjESHQE7UbtAAvkHGaDETxLrVLtGMvisL2IdaNIaP2elP/90hs7ByAcJ8AV9Tj PrfJf1re8Raq/K9+7djfC8iyVEJzL4muclFt96aotaoK8MxqKJSAbR/k8S2oslfwT9 TWRD92vu8jrP1UuYm6WjHt1UwPr8D3TPi/z9iyfc0k5jgu60v7lX+6kIQzLLYfXIDw p1fc5HLPZWCL7cMuQjq6z7ME1l30LdzFMkSY3iZ+zH2zxKoc09njoE0r2HQZsswm3Y OK1bkB6ncn6jGpBVKrxDgwd7n61ZBtSDHPMdj68PR1jmWUnbTKhG9Jw2cnG9m6Zhlf HzCIEMMUwjB1A== From: sashiko-bot@kernel.org Subject: Re: [PATCH RFC RESEND 4/7] i3c: master: Reject IBI requests from non-IBI-capable devices To: "Adrian Hunter" Cc: linux-i3c@lists.infradead.org, "Alexandre Belloni" , linux-pci@vger.kernel.org, Frank.Li@kernel.org In-Reply-To: <20260701201533.220818-5-adrian.hunter@intel.com> References: <20260701201533.220818-1-adrian.hunter@intel.com> <20260701201533.220818-5-adrian.hunter@intel.com> Date: Wed, 01 Jul 2026 20:29:04 +0000 Message-Id: <20260701202905.779531F000E9@smtp.kernel.org> X-BeenThere: linux-i3c@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sashiko-reviews@lists.linux.dev MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-i3c" Errors-To: linux-i3c-bounces+linux-i3c=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg MyBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpQcmUtZXhpc3RpbmcgaXNzdWVzOgot IFtDcml0aWNhbF0gTG9ja2xlc3MgYWNjZXNzIHRvIGBkZXYtPmliaWAgZnJvbSBpbnRlcnJ1cHQg Y29udGV4dCByYWNlcyB3aXRoIG5vbi1hdG9taWMgcG9pbnRlciBjbGVhcmluZywgY2F1c2luZyBh IHBvdGVudGlhbCBVc2UtQWZ0ZXItRnJlZS4KLSBbSGlnaF0gUmVjdXJzaXZlIHJlYWQgbG9jayBh Y3F1aXNpdGlvbiBvZiBgYnVzLT5sb2NrYCBsZWFkaW5nIHRvIHBvdGVudGlhbCBBQi1CQSBkZWFk bG9jayB3aXRoIHdyaXRlcnMuCi0gW0hpZ2hdIE1lbW9yeSBhbmQgcmVzb3VyY2UgbGVhayBvZiB0 aGUgSUJJIHdvcmtxdWV1ZSBvbiB0aGUgZXJyb3IgcGF0aCBvZiBgaTNjX2Rldl9yZXF1ZXN0X2li aV9sb2NrZWRgLgotLQoKY29tbWl0IGY2OWNmYWUzYmUyZWVhMzU2NDFhN2QwNDM1YTQxNzEyMDFk MzYyZWEKQXV0aG9yOiBBZHJpYW4gSHVudGVyIDxhZHJpYW4uaHVudGVyQGludGVsLmNvbT4KCmkz YzogbWFzdGVyOiBSZWplY3QgSUJJIHJlcXVlc3RzIGZyb20gbm9uLUlCSS1jYXBhYmxlIGRldmlj ZXMKCmkzY19kZXZpY2VfcmVxdWVzdF9pYmkoKSBkb2VzIG5vdCB2ZXJpZnkgdGhhdCBhIGRldmlj ZSBhZHZlcnRpc2VzIElCSQpzdXBwb3J0IGJlZm9yZSBhdHRlbXB0aW5nIHRvIHNldCB1cCBJQkkg aGFuZGxpbmcuIEFkZCBhIGNoZWNrIGZvcgpJM0NfQkNSX0lCSV9SRVFfQ0FQIGFuZCBmYWlsIHdp dGggLUVPUE5PVFNVUFAgd2hlbiBJQkkgc3VwcG9ydCBpcyBub3QKcmVwb3J0ZWQgYnkgdGhlIGRl dmljZS4KCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvaTNjL2RldmljZS5jIGIvZHJpdmVycy9pM2Mv ZGV2aWNlLmMKPiBpbmRleCAxMDFlYWE3N2RlNjg2Li4zMDdjYTZkYzA0Y2EwIDEwMDY0NAo+IC0t LSBhL2RyaXZlcnMvaTNjL2RldmljZS5jCj4gKysrIGIvZHJpdmVycy9pM2MvZGV2aWNlLmMKPiBA QCAtMjA1LDEyICsyMDUsMTQgQEAgaW50IGkzY19kZXZpY2VfcmVxdWVzdF9pYmkoc3RydWN0IGkz Y19kZXZpY2UgKmRldiwKPiAgCQlyZXR1cm4gcmV0Owo+ICAKPiAgCWkzY19idXNfbm9ybWFsdXNl X2xvY2soZGV2LT5idXMpOwoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzIGEgcHJlLWV4aXN0aW5n IGlzc3VlLCBidXQgY2FuIHRoaXMgY2F1c2UgYSBkZWFkbG9jayB3aXRoIHdyaXRlcnMKaWYgYSB3 cml0ZXIgYXJyaXZlcyBiZXR3ZWVuIHR3byBkb3duX3JlYWQoKSBjYWxscz8KCkluIGRyaXZlcnMv aTNjL21hc3Rlci5jOmkzY19tYXN0ZXJfcmVnX3dvcmtfZm4oKSwgdGhlIGZpcnN0IHJlYWQgbG9j ayBpcwphY3F1aXJlZCBiZWZvcmUgdHJpZ2dlcmluZyBzeW5jaHJvbm91cyBkZXZpY2UgcmVnaXN0 cmF0aW9uOgoKCWkzY19idXNfbm9ybWFsdXNlX2xvY2soJm1hc3Rlci0+YnVzKTsKCWlmICghbWFz dGVyLT5zaHV0dGluZ19kb3duKQoJCWkzY19tYXN0ZXJfcmVnaXN0ZXJfbmV3X2kzY19kZXZzKG1h c3Rlcik7CgpUaGlzIHN5bmNocm9ub3VzIHByb2JlIHBhdGggdGhlbiBjYWxscyBpM2NfZGV2aWNl X3JlcXVlc3RfaWJpKCksIHdoaWNoCnJlY3Vyc2l2ZWx5IGF0dGVtcHRzIHRvIGFjcXVpcmUgdGhl IHNhbWUgbG9jay4gSWYgYSB3cml0ZXIgc3VjaCBhcwppM2NfYnVzX21haW50ZW5hbmNlX2xvY2so KSAod2hpY2ggdGFrZXMgZG93bl93cml0ZSkgYXJyaXZlcyBiZXR3ZWVuIHRoZQp0d28gZG93bl9y ZWFkKCkgY2FsbHMsIHRoZSBzZWNvbmQgZG93bl9yZWFkKCkgYmxvY2tzIHRvIHByZXZlbnQgd3Jp dGVyCnN0YXJ2YXRpb24sIHdoaWxlIHRoZSB3cml0ZXIgYmxvY2tzIHdhaXRpbmcgZm9yIHRoZSBm aXJzdCByZWFkZXIuCgo+IC0JaWYgKGRldi0+ZGVzYykgewo+ICsJaWYgKCFkZXYtPmRlc2MpIHsK PiArCQlyZXQgPSAtRU5PRU5UOwo+ICsJfSBlbHNlIGlmICghKGRldi0+ZGVzYy0+aW5mby5iY3Ig JiBJM0NfQkNSX0lCSV9SRVFfQ0FQKSkgewo+ICsJCXJldCA9IC1FT1BOT1RTVVBQOwo+ICsJfSBl bHNlIHsKPiAgCQltdXRleF9sb2NrKCZkZXYtPmRlc2MtPmliaV9sb2NrKTsKPiAgCQlyZXQgPSBp M2NfZGV2X3JlcXVlc3RfaWJpX2xvY2tlZChkZXYtPmRlc2MsIHJlcSk7CgpbU2V2ZXJpdHk6IEhp Z2hdClRoaXMgaXMgYSBwcmUtZXhpc3RpbmcgaXNzdWUsIGJ1dCBkb2VzIHRoaXMgY29kZSBsZWFr IHRoZSB3b3JrcXVldWUgb24KdGhlIGVycm9yIHBhdGg/CgpMb29raW5nIGF0IGRyaXZlcnMvaTNj L21hc3Rlci5jOmkzY19kZXZfcmVxdWVzdF9pYmlfbG9ja2VkKCk6CgoJaWJpLT53cSA9IGFsbG9j X29yZGVyZWRfd29ya3F1ZXVlKGRldl9uYW1lKGkzY2Rldl90b19kZXYoZGV2LT5kZXYpKSwgV1Ff TUVNX1JFQ0xBSU0pOwoJLi4uCglyZXQgPSBtYXN0ZXItPm9wcy0+cmVxdWVzdF9pYmkoZGV2LCBy ZXEpOwoJaWYgKHJldCkgewoJCWtmcmVlKGliaSk7CgkJZGV2LT5pYmkgPSBOVUxMOwoJfQoKSWYg bWFzdGVyLT5vcHMtPnJlcXVlc3RfaWJpKCkgZmFpbHMsIHRoZSBpYmkgc3RydWN0IGlzIGZyZWVk IGJ1dCB0aGVyZQppcyBubyBjYWxsIHRvIGRlc3Ryb3lfd29ya3F1ZXVlKGliaS0+d3EpLCBwZXJt YW5lbnRseSBsZWFraW5nIHRoZSBtZW1vcnkKYW5kIGFzc29jaWF0ZWQga2VybmVsIHRocmVhZCBy ZXNvdXJjZXMuCgoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzIGEgcHJlLWV4aXN0aW5nIGlzc3Vl LCBidXQgY291bGQgdGhpcyBsZWFkIHRvIGEgdXNlLWFmdGVyLWZyZWUKaWYgYW4gaW50ZXJydXB0 IGhhbmRsZXIgYWNjZXNzZXMgZGV2LT5pYmkgY29uY3VycmVudGx5PwoKSW4gZHJpdmVycy9pM2Mv bWFzdGVyLmM6aTNjX21hc3Rlcl9xdWV1ZV9pYmkoKSwgdGhlIGhhcmR3YXJlIGludGVycnVwdApo YW5kbGVyIHJlYWRzIGRldi0+aWJpIGxvY2tsZXNzbHkgdG8gcXVldWUgaW5jb21pbmcgSUJJczoK CglpZiAoIWRldi0+aWJpIHx8ICFzbG90KQoJCXJldHVybjsKCS4uLgoJYXRvbWljX2luYygmZGV2 LT5pYmktPnBlbmRpbmdfaWJpcyk7CglxdWV1ZV93b3JrKGRldi0+aWJpLT53cSwgJnNsb3QtPndv cmspOwoKSG93ZXZlciwgaW4gdGhlIGVycm9yIHBhdGggb2YgaTNjX2Rldl9yZXF1ZXN0X2liaV9s b2NrZWQoKSBzaG93biBhYm92ZSwKYW5kIGluIGkzY19kZXZfZnJlZV9pYmlfbG9ja2VkKCksIHRo ZSBtZW1vcnkgaXMgZnJlZWQgYmVmb3JlIHRoZSBwb2ludGVyCmlzIGNsZWFyZWQ6CgoJa2ZyZWUo aWJpKTsKCWRldi0+aWJpID0gTlVMTDsKCkJlY2F1c2UgdGhlcmUgaXMgbm8gc3luY2hyb25pemF0 aW9uLCBhIGNvbmN1cnJlbnQgaW50ZXJydXB0IG9uIGFub3RoZXIKQ1BVIGNhbiByZWFkIHRoZSBw b2ludGVyLCBnZXQgZGVsYXllZCwgYW5kIHRoZW4gZGVyZWZlcmVuY2UgaXQgYWZ0ZXIgaXQKaGFz IGJlZW4gZnJlZWQuCgo+ICAJCW11dGV4X3VubG9jaygmZGV2LT5kZXNjLT5pYmlfbG9jayk7Cj4g LQl9IGVsc2Ugewo+IC0JCXJldCA9IC1FTk9FTlQ7Cj4gIAl9Cj4gIAlpM2NfYnVzX25vcm1hbHVz ZV91bmxvY2soZGV2LT5idXMpOwo+CgotLSAKU2FzaGlrbyBBSSByZXZpZXcgwrcgaHR0cHM6Ly9z YXNoaWtvLmRldi8jL3BhdGNoc2V0LzIwMjYwNzAxMjAxNTMzLjIyMDgxOC0xLWFkcmlhbi5odW50 ZXJAaW50ZWwuY29tP3BhcnQ9NAoKLS0gCmxpbnV4LWkzYyBtYWlsaW5nIGxpc3QKbGludXgtaTNj QGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9s aXN0aW5mby9saW51eC1pM2MK From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 368C927A47F for ; Wed, 1 Jul 2026 20:29:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782937747; cv=none; b=awQE8KS4gj6qv5nGCxq8VjQn/WURWVePbnLCcURvy462M7J8SEqGcByYtOjYRuByp/4R34FmxeqoFj1g7FaDy4pbDBIEeFHydTlAMY8tJ3zfFQAN9sQXzP5wyZyugcnI8uK/PGuIaKXJO6M3/5TTeVdnBIuV8htbTxWjohc/mUg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782937747; c=relaxed/simple; bh=qhCO48VVcv1hmtEzsYr2/UgAHVi3xGjK5D8W3hxq9Kk=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=f6xjYLzKa9Mk7KD+82iHj4eizlp5vA6sf/9rWk8vco4tJTX3QgQp0/xlcihR+qo3SlHvNJl2Dd/DLW+oRIm55Gl61a1VuOGspDEM1fe0fxHuq25Qf8Py4KnVhZOfpCaTvU5ihaaHMEeN32ROmQHywaVjB3z8QZSXuUVw6RM5eW0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=n3tLjESH; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="n3tLjESH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 779531F000E9; Wed, 1 Jul 2026 20:29:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782937745; bh=Dr+I3p8ZIjxW6pp0wwweggYhAj35PUYgw3Cl0InNCvo=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=n3tLjESHQE7UbtAAvkHGaDETxLrVLtGMvisL2IdaNIaP2elP/90hs7ByAcJ8AV9Tj PrfJf1re8Raq/K9+7djfC8iyVEJzL4muclFt96aotaoK8MxqKJSAbR/k8S2oslfwT9 TWRD92vu8jrP1UuYm6WjHt1UwPr8D3TPi/z9iyfc0k5jgu60v7lX+6kIQzLLYfXIDw p1fc5HLPZWCL7cMuQjq6z7ME1l30LdzFMkSY3iZ+zH2zxKoc09njoE0r2HQZsswm3Y OK1bkB6ncn6jGpBVKrxDgwd7n61ZBtSDHPMdj68PR1jmWUnbTKhG9Jw2cnG9m6Zhlf HzCIEMMUwjB1A== From: sashiko-bot@kernel.org Subject: Re: [PATCH RFC RESEND 4/7] i3c: master: Reject IBI requests from non-IBI-capable devices Reply-To: sashiko-reviews@lists.linux.dev To: "Adrian Hunter" Cc: linux-i3c@lists.infradead.org, "Alexandre Belloni" , linux-pci@vger.kernel.org, Frank.Li@kernel.org In-Reply-To: <20260701201533.220818-5-adrian.hunter@intel.com> References: <20260701201533.220818-1-adrian.hunter@intel.com> <20260701201533.220818-5-adrian.hunter@intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 01 Jul 2026 20:29:04 +0000 Message-Id: <20260701202905.779531F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: linux-pci@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 3 potential issue(= s) to consider: Pre-existing issues: - [Critical] Lockless access to `dev->ibi` from interrupt context races wit= h non-atomic pointer clearing, causing a potential Use-After-Free. - [High] Recursive read lock acquisition of `bus->lock` leading to potentia= l AB-BA deadlock with writers. - [High] Memory and resource leak of the IBI workqueue on the error path of= `i3c_dev_request_ibi_locked`. -- commit f69cfae3be2eea35641a7d0435a4171201d362ea Author: Adrian Hunter i3c: master: Reject IBI requests from non-IBI-capable devices i3c_device_request_ibi() does not verify that a device advertises IBI support before attempting to set up IBI handling. Add a check for I3C_BCR_IBI_REQ_CAP and fail with -EOPNOTSUPP when IBI support is not reported by the device. > diff --git a/drivers/i3c/device.c b/drivers/i3c/device.c > index 101eaa77de686..307ca6dc04ca0 100644 > --- a/drivers/i3c/device.c > +++ b/drivers/i3c/device.c > @@ -205,12 +205,14 @@ int i3c_device_request_ibi(struct i3c_device *dev, > return ret; > =20 > i3c_bus_normaluse_lock(dev->bus); [Severity: High] This is a pre-existing issue, but can this cause a deadlock with writers if a writer arrives between two down_read() calls? In drivers/i3c/master.c:i3c_master_reg_work_fn(), the first read lock is acquired before triggering synchronous device registration: i3c_bus_normaluse_lock(&master->bus); if (!master->shutting_down) i3c_master_register_new_i3c_devs(master); This synchronous probe path then calls i3c_device_request_ibi(), which recursively attempts to acquire the same lock. If a writer such as i3c_bus_maintenance_lock() (which takes down_write) arrives between the two down_read() calls, the second down_read() blocks to prevent writer starvation, while the writer blocks waiting for the first reader. > - if (dev->desc) { > + if (!dev->desc) { > + ret =3D -ENOENT; > + } else if (!(dev->desc->info.bcr & I3C_BCR_IBI_REQ_CAP)) { > + ret =3D -EOPNOTSUPP; > + } else { > mutex_lock(&dev->desc->ibi_lock); > ret =3D i3c_dev_request_ibi_locked(dev->desc, req); [Severity: High] This is a pre-existing issue, but does this code leak the workqueue on the error path? Looking at drivers/i3c/master.c:i3c_dev_request_ibi_locked(): ibi->wq =3D alloc_ordered_workqueue(dev_name(i3cdev_to_dev(dev->dev)), WQ_= MEM_RECLAIM); ... ret =3D master->ops->request_ibi(dev, req); if (ret) { kfree(ibi); dev->ibi =3D NULL; } If master->ops->request_ibi() fails, the ibi struct is freed but there is no call to destroy_workqueue(ibi->wq), permanently leaking the memory and associated kernel thread resources. [Severity: High] This is a pre-existing issue, but could this lead to a use-after-free if an interrupt handler accesses dev->ibi concurrently? In drivers/i3c/master.c:i3c_master_queue_ibi(), the hardware interrupt handler reads dev->ibi locklessly to queue incoming IBIs: if (!dev->ibi || !slot) return; ... atomic_inc(&dev->ibi->pending_ibis); queue_work(dev->ibi->wq, &slot->work); However, in the error path of i3c_dev_request_ibi_locked() shown above, and in i3c_dev_free_ibi_locked(), the memory is freed before the pointer is cleared: kfree(ibi); dev->ibi =3D NULL; Because there is no synchronization, a concurrent interrupt on another CPU can read the pointer, get delayed, and then dereference it after it has been freed. > mutex_unlock(&dev->desc->ibi_lock); > - } else { > - ret =3D -ENOENT; > } > i3c_bus_normaluse_unlock(dev->bus); > --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260701201533.2208= 18-1-adrian.hunter@intel.com?part=3D4