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 C04B8C56208 for ; Thu, 6 Aug 2026 13:39:16 +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=dPF8HSwcbsCPoQTOlrgKiF6jAEIxBC9m5iWd0058ECw=; b=Lp4nQrRpg3jIc5 Ih4dGwbqHtCKGZUeCIk19s9J69ppNJ3CRJcYZ35ffBBelvAluKmNOvCelMUYzWDw3Tcf8U9vCQhvg 2bxKntl/Uv63i0hwMR/h05sow2JBmnB3ziGh2Kpo5eClxv3sA4+nOoViBOkT1sD3W9ntX37g3J+bI DQnH/vQGbwZiAyknp5dPPvFo4ZM/cOFCDjUJN9b3wR4ekR4pmDjwN7goNQ3H+fjRGGZfeRj2y1IrS z85DBoBUN3aphs0Y/yJtBWOD1Jtz0BpHuo2DTU1hEiAeFThSBrWS157FkX95h7qH+fvoXKcK4VDoo D0Sn+Dp8/UNMVIY8ghIg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wryJY-00000005vTx-242z; Thu, 06 Aug 2026 13:39:16 +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 1wryJX-00000005vTY-3FHY for linux-i3c@lists.infradead.org; Thu, 06 Aug 2026 13:39:15 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 578B0408CC; Thu, 6 Aug 2026 13:39:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EDA761F000E9; Thu, 6 Aug 2026 13:39:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786023555; bh=F+I+ddnxFvrQEUitPJJrfAfpCyBasFub3M63eWzfy54=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=EQlZQI3sBRE7RtPnJRrinAVBnsrwbK695BmLC+V8qPN8D02Bz8JX0GdAt4dsjPb2Q mewXqHQGgtKaNGYY+gLMaue6OGkLSYpyp8Vdob9Wz0u7APeRSjmSidfxioDu0AMNNI fXNsGaQdQWf4SXfOkukVk4WqKnMWQFGv3HceuSSS5sixoesHMd1MaYQRLXtTr/EcnG IGBzQu7smWtad7XP4DP70cp3/lUSbqAUlhkg45Doo4Q9D/snkU2x85excnxpTOpUEe 7u22lPpN83Xo0IC4foGNRFrXrNtNLMEOIHlvQVqZ67Nj3ikEg+MCkYJUluVcIL0Hzi ZZXcxyTVS+RkQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH V4 01/14] i3c: master: Fix recursive locking during device registration To: "Adrian Hunter" Cc: "Alexandre Belloni" , linux-pci@vger.kernel.org, Frank.Li@kernel.org, linux-i3c@lists.infradead.org In-Reply-To: <20260806131857.119830-2-adrian.hunter@intel.com> References: <20260806131857.119830-1-adrian.hunter@intel.com> <20260806131857.119830-2-adrian.hunter@intel.com> Date: Thu, 06 Aug 2026 13:39:14 +0000 Message-Id: <20260806133914.EDA761F000E9@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 MiBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtIaWdoXSBE cm9wcGluZyB0aGUgYnVzIG1haW50ZW5hbmNlIGxvY2sgYXJvdW5kIGRldmljZV9yZWdpc3Rlcigp IGV4cG9zZXMgdGhlIEkzQyBkZXZpY2UgZGVzY3JpcHRvciB0byBjb25jdXJyZW50IFVzZS1BZnRl ci1GcmVlLgoKUHJlLWV4aXN0aW5nIGlzc3VlczoKLSBbSGlnaF0gVW5iYWxhbmNlZCBmd25vZGUg cmVmZXJlbmNlIGNvdW50IGRlY3JlbWVudCBpbiBpM2NfZGV2aWNlX3JlbGVhc2UoKSBsZWFkcyB0 byBVc2UtQWZ0ZXItRnJlZS4KLS0KCi0tLSBQYXRjaCBbMV06IFtQQVRDSCBWNCAwMS8xNF0gaTNj OiBtYXN0ZXI6IEZpeCByZWN1cnNpdmUgbG9ja2luZyBkdXJpbmcgZGV2aWNlIHJlZ2lzdHJhdGlv biAtLS0KY29tbWl0IGIzMWE4NDgyYWEyZWE3MTBjY2M4NTNkMGM3NGI3N2VkZWJiMTMxZmYKQXV0 aG9yOiBBZHJpYW4gSHVudGVyIDxhZHJpYW4uaHVudGVyQGludGVsLmNvbT4KRGF0ZTogICBUaHUg QXVnIDYgMTM6MTg6NDQgMjAyNiArMDAwMAoKICAgIGkzYzogbWFzdGVyOiBGaXggcmVjdXJzaXZl IGxvY2tpbmcgZHVyaW5nIGRldmljZSByZWdpc3RyYXRpb24KClRoaXMgY29tbWl0IGFkZHJlc3Nl cyBhIHJlY3Vyc2l2ZSBsb2NraW5nIGxvY2tkZXAgd2FybmluZyBieSBkZWNvdXBsaW5nCmRldmlj ZSBjcmVhdGlvbiBmcm9tIHJlZ2lzdHJhdGlvbi4gSXQgY29sbGVjdHMgbmV3bHkgcG9wdWxhdGVk IGRldmljZXMgaW50byBhCnRlbXBvcmFyeSBsaXN0IHVuZGVyIHRoZSBtYWludGVuYW5jZSBsb2Nr LCB0aGVuIHJlbGVhc2VzIHRoZSBsb2NrIHByaW9yIHRvCmludm9raW5nIGRldmljZV9yZWdpc3Rl cigpIHRvIHByZXZlbnQgcHJvYmUgZGVhZGxvY2tzLiBGaW5hbGx5LCB0aGUgbG9jayBpcwpyZS1h Y3F1aXJlZCB0byBjbGVhbiB1cCBhbnkgZGV2aWNlcyB0aGF0IGZhaWxlZCByZWdpc3RyYXRpb24u Cgo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2kzYy9tYXN0ZXIuYyBiL2RyaXZlcnMvaTNjL21hc3Rl ci5jCj4gLS0tIGEvZHJpdmVycy9pM2MvbWFzdGVyLmMKPiArKysgYi9kcml2ZXJzL2kzYy9tYXN0 ZXIuYwo+IEBAIC0yMTA0LDI1ICsyMTEzLDM3IEBAIGkzY19tYXN0ZXJfcmVnaXN0ZXJfbmV3X2kz Y19kZXZzKHN0cnVjdCBpM2NfbWFzdGVyX2NvbnRyb2xsZXIgKm1hc3RlcikKClsgLi4uIF0KCj4g KwkJbGlzdF9hZGRfdGFpbCgmZGVzYy0+ZGV2LT5ub2RlLCAmaTNjX3VucmVnX2RldnMpOwo+ICsJ fQo+ICsKPiArCWkzY19idXNfbWFpbnRlbmFuY2VfdW5sb2NrKCZtYXN0ZXItPmJ1cyk7Cj4gKwo+ ICsJbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKGkzY2RldiwgdG1wLCAmaTNjX3VucmVnX2RldnMs IG5vZGUpIHsKPiArCQlyZXQgPSBkZXZpY2VfcmVnaXN0ZXIoJmkzY2Rldi0+ZGV2KTsKCltTZXZl cml0eTogSGlnaF0KRG9lcyBkcm9wcGluZyB0aGUgYnVzIG1haW50ZW5hbmNlIGxvY2sgYXJvdW5k IGRldmljZV9yZWdpc3RlcigpIGV4cG9zZSB0aGUKSTNDIGRldmljZSBkZXNjcmlwdG9yIHRvIGEg Y29uY3VycmVudCB1c2UtYWZ0ZXItZnJlZT8KCkR1cmluZyByZWdpc3RyYXRpb24sIHRoZSBkcml2 ZXIgY29yZSBjYW4gY2FsbCBzdWJzeXN0ZW0gZnVuY3Rpb25zIGxpa2UKaTNjX2RldmljZV9tYXRj aCgpLCB3aGljaCByZWFkIGkzY2Rldi0+ZGVzYyBsb2NrbGVzc2x5OgoKZHJpdmVycy9pM2MvbWFz dGVyLmM6aTNjX2RldmljZV9tYXRjaCgpIHsKICAgIC4uLgogICAgaWYgKGkzY2Rldi0+ZGVzYyAm JiBpM2NkZXYtPmRlc2MtPmJvYXJkaW5mbykKICAgICAgICBzdGF0aWNfYWRkcl9tZXRob2QgPSBp M2NkZXYtPmRlc2MtPmJvYXJkaW5mby0+c3RhdGljX2FkZHJfbWV0aG9kOwogICAgLi4uCn0KCkNv bmN1cnJlbnRseSwgYW4gSTNDIEhvdC1Kb2luIG9yIHN5c2ZzLXRyaWdnZXJlZCBEeW5hbWljIEFk ZHJlc3MgQXNzaWdubWVudAooREFBKSBjb3VsZCBleGVjdXRlIGkzY19tYXN0ZXJfZG9fZGFhKCks IHRha2UgdGhlIGkzY19idXNfbWFpbnRlbmFuY2VfbG9jaywKYW5kIGNhbGwgX19pM2NfbWFzdGVy X2FkZF9pM2NfZGV2X2xvY2tlZCgpLiBJZiBEQUEgZGV0ZWN0cyB0aGUgZGV2aWNlIGFzIGEKZHVw bGljYXRlLCBpdCByZXBsYWNlcyB0aGUgZGVzY3JpcHRvciBhbmQgZnJlZXMgdGhlIG9sZCBvbmU6 Cgpkcml2ZXJzL2kzYy9tYXN0ZXIuYzpfX2kzY19tYXN0ZXJfYWRkX2kzY19kZXZfbG9ja2VkKCkg ewogICAgLi4uCiAgICBpM2NfbWFzdGVyX2RldGFjaF9pM2NfZGV2KG9sZGRldik7CiAgICBpM2Nf bWFzdGVyX2ZyZWVfaTNjX2RldihvbGRkZXYpOwogICAgLi4uCn0KCklmIHRoZSByZWdpc3Rlcmlu ZyB0aHJlYWQgaXMgYWN0aXZlbHkgZXZhbHVhdGluZyBpM2NkZXYtPmRlc2Mgd2hlbiB0aGlzCmhh cHBlbnMsIHdpbGwgaXQgbGVhZCB0byBtZW1vcnkgY29ycnVwdGlvbiB3aGVuIHJlYWRpbmcgZmll bGRzIGxpa2UKZGVzYy0+Ym9hcmRpbmZvPwoKPiArCQlpZiAocmV0KQo+ICsJCQlkZXZfZXJyKCZt YXN0ZXItPmRldiwgIkZhaWxlZCB0byBhZGQgSTNDIGRldmljZSAoZXJyID0gJWQpXG4iLCByZXQp Owo+ICsJCWVsc2UKPiArCQkJbGlzdF9kZWxfaW5pdCgmaTNjZGV2LT5ub2RlKTsKPiArCX0KPiAr Cj4gKwlpM2NfYnVzX21haW50ZW5hbmNlX2xvY2soJm1hc3Rlci0+YnVzKTsKPiArCj4gKwlsaXN0 X2Zvcl9lYWNoX2VudHJ5X3NhZmUoaTNjZGV2LCB0bXAsICZpM2NfdW5yZWdfZGV2cywgbm9kZSkg ewo+ICsJCWxpc3RfZGVsKCZpM2NkZXYtPm5vZGUpOwo+ICsJCWRlc2MgPSBpM2NkZXYtPmRlc2M7 Cj4gKwkJaTNjZGV2LT5kZXNjID0gTlVMTDsKPiArCQlwdXRfZGV2aWNlKCZpM2NkZXYtPmRldik7 CgpbU2V2ZXJpdHk6IEhpZ2hdClRoaXMgaXMgYSBwcmUtZXhpc3RpbmcgaXNzdWUsIGJ1dCBkb2Vz IHRoaXMgZXJyb3IgcGF0aCBjYXVzZSBhbiB1bmJhbGFuY2VkCmZ3bm9kZSByZWZlcmVuY2UgY291 bnQgZGVjcmVtZW50IGxlYWRpbmcgdG8gYSB1c2UtYWZ0ZXItZnJlZT8KCkR1cmluZyBkZXZpY2Ug aW5pdGlhbGl6YXRpb24sIGRldmljZV9zZXRfbm9kZSgpIGFzc2lnbnMgdGhlIGZ3bm9kZSB3aXRo b3V0CmluY3JlbWVudGluZyBpdHMgcmVmZXJlbmNlIGNvdW50OgoKZHJpdmVycy9pM2MvbWFzdGVy LmM6aTNjX21hc3Rlcl9yZWdpc3Rlcl9uZXdfaTNjX2RldnMoKSB7CiAgICAuLi4KICAgIGlmIChk ZXNjLT5ib2FyZGluZm8pCiAgICAgICAgZGV2aWNlX3NldF9ub2RlKCZkZXNjLT5kZXYtPmRldiwg ZGVzYy0+Ym9hcmRpbmZvLT5md25vZGUpOwogICAgLi4uCn0KCkhvd2V2ZXIsIHdoZW4gcHV0X2Rl dmljZSgpIGlzIGNhbGxlZCBoZXJlIG9uIHJlZ2lzdHJhdGlvbiBmYWlsdXJlLAp0aGUgcmVsZWFz ZSBmdW5jdGlvbiB1bmNvbmRpdGlvbmFsbHkgZHJvcHMgYSByZWZlcmVuY2U6Cgpkcml2ZXJzL2kz Yy9tYXN0ZXIuYzppM2NfZGV2aWNlX3JlbGVhc2UoKSB7CiAgICAuLi4KICAgIGZ3bm9kZV9oYW5k bGVfcHV0KGRldi0+Zndub2RlKTsKICAgIC4uLgp9CgpTaW5jZSB0aGUgZGV2aWNlIG9iamVjdCBu ZXZlciBhY3F1aXJlZCBhIHJlZmVyZW5jZSB0byB0aGUgYm9hcmRpbmZvJ3MgZndub2RlLAp3aWxs IHJlcGVhdGVkIHJlZ2lzdHJhdGlvbiBmYWlsdXJlcyBvciB1bmJpbmQgb3BlcmF0aW9ucyBkcm9w IHRoZSByZWZjb3VudApiZWxvdyB6ZXJvLCBldmVudHVhbGx5IHByZW1hdHVyZWx5IGZyZWVpbmcg dGhlIGZ3bm9kZT8KCj4gKwkJZGVzYy0+ZGV2ID0gTlVMTDsKPiAgCX0KPiArCj4gKwlpM2NfYnVz X21haW50ZW5hbmNlX3VubG9jaygmbWFzdGVyLT5idXMpOwo+ICB9CgotLSAKU2FzaGlrbyBBSSBy ZXZpZXcgwrcgaHR0cHM6Ly9zYXNoaWtvLmRldi8jL3BhdGNoc2V0LzIwMjYwODA2MTMxODU3LjEx OTgzMC0xLWFkcmlhbi5odW50ZXJAaW50ZWwuY29tP3BhcnQ9MQoKLS0gCmxpbnV4LWkzYyBtYWls aW5nIGxpc3QKbGludXgtaTNjQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJh ZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1pM2MK 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 BA475380FCD for ; Thu, 6 Aug 2026 13:39:16 +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=1786023562; cv=none; b=UFY8yAWUceLEtv2qREnUFv7qe63zO/CrT2pPoZWNxdLEslAuVgOGkVnQH2cxNd8B/4MiX6d6HPU8OU6VZMqiINZt2+JMh5JRln0vqrc15R5WWUDS3KvAKnDjR88QkgrIaMWPoAQBeEBZpdtRvR5n6REAUaA5CzM2JhLlpC21Q90= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786023562; c=relaxed/simple; bh=WsXeVu+7T5dXUHPhNbT0eMNiwxXJu1ODZQcEjYUXUjY=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=SCl/LNeNT4V1IMFjlCIo2Li9TpTyhF9OcoopbcNPlNJxgfm5cMkGLuG5jysfrP8HXtENhRNQHRAiZRWzTJZSyk5jPuTBmbBzmeuwrXjmb2G4HYrDohmk5jm9c87kT4xFb2vtYbcqzsNYiHXkFGhQl0Vh8EZTEC14+37WVz7MYO8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EQlZQI3s; 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="EQlZQI3s" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EDA761F000E9; Thu, 6 Aug 2026 13:39:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786023555; bh=F+I+ddnxFvrQEUitPJJrfAfpCyBasFub3M63eWzfy54=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=EQlZQI3sBRE7RtPnJRrinAVBnsrwbK695BmLC+V8qPN8D02Bz8JX0GdAt4dsjPb2Q mewXqHQGgtKaNGYY+gLMaue6OGkLSYpyp8Vdob9Wz0u7APeRSjmSidfxioDu0AMNNI fXNsGaQdQWf4SXfOkukVk4WqKnMWQFGv3HceuSSS5sixoesHMd1MaYQRLXtTr/EcnG IGBzQu7smWtad7XP4DP70cp3/lUSbqAUlhkg45Doo4Q9D/snkU2x85excnxpTOpUEe 7u22lPpN83Xo0IC4foGNRFrXrNtNLMEOIHlvQVqZ67Nj3ikEg+MCkYJUluVcIL0Hzi ZZXcxyTVS+RkQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH V4 01/14] i3c: master: Fix recursive locking during device registration Reply-To: sashiko-reviews@lists.linux.dev To: "Adrian Hunter" Cc: "Alexandre Belloni" , linux-pci@vger.kernel.org, Frank.Li@kernel.org, linux-i3c@lists.infradead.org In-Reply-To: <20260806131857.119830-2-adrian.hunter@intel.com> References: <20260806131857.119830-1-adrian.hunter@intel.com> <20260806131857.119830-2-adrian.hunter@intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 06 Aug 2026 13:39:14 +0000 Message-Id: <20260806133914.EDA761F000E9@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 2 potential issue(= s) to consider: New issues: - [High] Dropping the bus maintenance lock around device_register() exposes= the I3C device descriptor to concurrent Use-After-Free. Pre-existing issues: - [High] Unbalanced fwnode reference count decrement in i3c_device_release(= ) leads to Use-After-Free. -- --- Patch [1]: [PATCH V4 01/14] i3c: master: Fix recursive locking during d= evice registration --- commit b31a8482aa2ea710ccc853d0c74b77edebb131ff Author: Adrian Hunter Date: Thu Aug 6 13:18:44 2026 +0000 i3c: master: Fix recursive locking during device registration This commit addresses a recursive locking lockdep warning by decoupling device creation from registration. It collects newly populated devices into= a temporary list under the maintenance lock, then releases the lock prior to invoking device_register() to prevent probe deadlocks. Finally, the lock is re-acquired to clean up any devices that failed registration. > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c > --- a/drivers/i3c/master.c > +++ b/drivers/i3c/master.c > @@ -2104,25 +2113,37 @@ i3c_master_register_new_i3c_devs(struct i3c_maste= r_controller *master) [ ... ] > + list_add_tail(&desc->dev->node, &i3c_unreg_devs); > + } > + > + i3c_bus_maintenance_unlock(&master->bus); > + > + list_for_each_entry_safe(i3cdev, tmp, &i3c_unreg_devs, node) { > + ret =3D device_register(&i3cdev->dev); [Severity: High] Does dropping the bus maintenance lock around device_register() expose the I3C device descriptor to a concurrent use-after-free? During registration, the driver core can call subsystem functions like i3c_device_match(), which read i3cdev->desc locklessly: drivers/i3c/master.c:i3c_device_match() { ... if (i3cdev->desc && i3cdev->desc->boardinfo) static_addr_method =3D i3cdev->desc->boardinfo->static_addr_method; ... } Concurrently, an I3C Hot-Join or sysfs-triggered Dynamic Address Assignment (DAA) could execute i3c_master_do_daa(), take the i3c_bus_maintenance_lock, and call __i3c_master_add_i3c_dev_locked(). If DAA detects the device as a duplicate, it replaces the descriptor and frees the old one: drivers/i3c/master.c:__i3c_master_add_i3c_dev_locked() { ... i3c_master_detach_i3c_dev(olddev); i3c_master_free_i3c_dev(olddev); ... } If the registering thread is actively evaluating i3cdev->desc when this happens, will it lead to memory corruption when reading fields like desc->boardinfo? > + if (ret) > + dev_err(&master->dev, "Failed to add I3C device (err =3D %d)\n", ret); > + else > + list_del_init(&i3cdev->node); > + } > + > + i3c_bus_maintenance_lock(&master->bus); > + > + list_for_each_entry_safe(i3cdev, tmp, &i3c_unreg_devs, node) { > + list_del(&i3cdev->node); > + desc =3D i3cdev->desc; > + i3cdev->desc =3D NULL; > + put_device(&i3cdev->dev); [Severity: High] This is a pre-existing issue, but does this error path cause an unbalanced fwnode reference count decrement leading to a use-after-free? During device initialization, device_set_node() assigns the fwnode without incrementing its reference count: drivers/i3c/master.c:i3c_master_register_new_i3c_devs() { ... if (desc->boardinfo) device_set_node(&desc->dev->dev, desc->boardinfo->fwnode); ... } However, when put_device() is called here on registration failure, the release function unconditionally drops a reference: drivers/i3c/master.c:i3c_device_release() { ... fwnode_handle_put(dev->fwnode); ... } Since the device object never acquired a reference to the boardinfo's fwnod= e, will repeated registration failures or unbind operations drop the refcount below zero, eventually prematurely freeing the fwnode? > + desc->dev =3D NULL; > } > + > + i3c_bus_maintenance_unlock(&master->bus); > } --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260806131857.1198= 30-1-adrian.hunter@intel.com?part=3D1