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 5F893C54F4D for ; Tue, 28 Jul 2026 16:19:38 +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=sATQyKKgM0SxvKZcunTizwNYMkFUG3jDdKm5UZhJfUs=; b=DTzvs/kiuQcIr9 bJE4CYT4NOFYbDR3mHHjWFeOjrDJ92hWor6hYWjgJy7t7+OwYElY+VMEpGRioDz4xOYSPWmDhlqqJ KfVJovhjt1RiXDRcRmRnTigBlA7g8N4iLAbjfgNnRDj1th8ZvR/z11JpI3eEqUtoR4XOLXmKZwKDX ++neveB30vh4p4wEAHWlYcdYfq9i5fr9LAkBfzyv+9n71uwdxn8kLpMoIgvHIHvq0jqRhPoE/Ust9 0A6cQBkZ/hz4eZ4Tt3JIZ76dnLjCuRY/WYGzXLuXBC9D2xQ0NoMG3whRdXBMANujy7M+ANNiesgBx EHzMY79vtyrZlrMrH3jg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wokWn-00000005oJH-2prT; Tue, 28 Jul 2026 16:19:37 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wokWm-00000005oIu-2l7O for linux-i3c@lists.infradead.org; Tue, 28 Jul 2026 16:19:36 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 2DD8342A21; Tue, 28 Jul 2026 16:19:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C236F1F00A3A; Tue, 28 Jul 2026 16:19:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785255576; bh=peruRkkKr+azNeAOQhOqjTEeC5FtrRlabTA5htTlFOA=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=Y0btHdfkjwL0gzq1s0PqOUlY3CsPtTmtOLrqnw40pBVKMez5Da3ejoxhhVOi/YneM OZcFINxFN4zwqGrSmMyVZznJ/MQ7iiiz3FWS1fW8dCZCwEmPLNbDXkN1300v2F9/6Q JbPhVMBJBnQ74ixqAqT9Nor30B3Agc3ehgtokogzqjI/BpkS903Zo870PgRdUPIclS VQNIx9UIvbJ46L6E0tdJuSVdd0zgy0i0citZsEZJSC8UGTyFufRI6ce/rdY1qrXP8E fb85w4TH6HsGur7q7i3nN9ZDEVK2FJwxwUFrWEJSgKBTpmgcntTbUyiatUImQLrEwh ICCovjhC9mQVw== From: sashiko-bot@kernel.org Subject: Re: [PATCH V2 1/8] i3c: master: Fix recursive locking during device registration To: "Adrian Hunter" Cc: Frank.Li@kernel.org, linux-pci@vger.kernel.org, linux-i3c@lists.infradead.org, "Alexandre Belloni" In-Reply-To: <20260728155308.142713-2-adrian.hunter@intel.com> References: <20260728155308.142713-1-adrian.hunter@intel.com> <20260728155308.142713-2-adrian.hunter@intel.com> Date: Tue, 28 Jul 2026 16:19:35 +0000 Message-Id: <20260728161935.C236F1F00A3A@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 IGV4cG9zZXMgaTNjX2RldmljZV91ZXZlbnQoKSBhbmQgZHJpdmVyIHByb2JlIGZ1bmN0aW9ucyB0 byBhIFVzZS1BZnRlci1GcmVlIGlmIGEgY29uY3VycmVudCBEQUEgcmVwbGFjZXMgdGhlIGRldmlj ZS4KClByZS1leGlzdGluZyBpc3N1ZXM6Ci0gW0hpZ2hdIGkzY19kZXZpY2VfdWV2ZW50KCkgbGVh a3MgdW5pbml0aWFsaXplZCBzdGFjayBtZW1vcnkgdG8gdXNlcnNwYWNlIHdoZW4gaTNjZGV2LT5k ZXNjIGlzIE5VTEwuCi0tCgotLS0gUGF0Y2ggWzFdOiBbUEFUQ0ggVjIgMS84XSBpM2M6IG1hc3Rl cjogRml4IHJlY3Vyc2l2ZSBsb2NraW5nIGR1cmluZyBkZXZpY2UgcmVnaXN0cmF0aW9uIC0tLQpj b21taXQgMzNhNGRjZDZjNTYyNmZhZWY5NWJjN2NkMDJlYzRjNTZjNjcxMGM3OApBdXRob3I6IEFk cmlhbiBIdW50ZXIgPGFkcmlhbi5odW50ZXJAaW50ZWwuY29tPgoKaTNjOiBtYXN0ZXI6IEZpeCBy ZWN1cnNpdmUgbG9ja2luZyBkdXJpbmcgZGV2aWNlIHJlZ2lzdHJhdGlvbgoKVGhpcyBjb21taXQg c2VwYXJhdGVzIGRldmljZSBjcmVhdGlvbiBmcm9tIHJlZ2lzdHJhdGlvbiB0byBmaXggYSByZWN1 cnNpdmUKbG9ja2luZyBpc3N1ZS4gSXQgZHJvcHMgdGhlIGJ1cyBtYWludGVuYW5jZSBsb2NrIGFy b3VuZCBkZXZpY2VfcmVnaXN0ZXIoKQp0byBwcmV2ZW50IGRlYWRsb2NrcyB3aGVuIHByb2JlIGNh bGxiYWNrcyBpbnZva2UgSTNDIGhlbHBlcnMuCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9pM2MvbWFz dGVyLmMgYi9kcml2ZXJzL2kzYy9tYXN0ZXIuYwppbmRleCBmZDNlNzlkMTBjODQwLi44NzRmNmUx MWIyOTZkIDEwMDY0NAotLS0gYS9kcml2ZXJzL2kzYy9tYXN0ZXIuYworKysgYi9kcml2ZXJzL2kz Yy9tYXN0ZXIuYwpbIC4uLiBdCj4gQEAgLTE5OTksMjUgKzIwMDgsMzcgQEAgaTNjX21hc3Rlcl9y ZWdpc3Rlcl9uZXdfaTNjX2RldnMoc3RydWN0IGkzY19tYXN0ZXJfY29udHJvbGxlciAqbWFzdGVy KQo+ICAJCWlmIChkZXNjLT5ib2FyZGluZm8pCj4gIAkJCWRlc2MtPmRldi0+ZGV2Lm9mX25vZGUg PSBkZXNjLT5ib2FyZGluZm8tPm9mX25vZGU7Cj4gIAo+IC0JCXJldCA9IGRldmljZV9yZWdpc3Rl cigmZGVzYy0+ZGV2LT5kZXYpOwo+IC0JCWlmIChyZXQpIHsKPiAtCQkJZGV2X2VycigmbWFzdGVy LT5kZXYsCj4gLQkJCQkiRmFpbGVkIHRvIGFkZCBJM0MgZGV2aWNlIChlcnIgPSAlZClcbiIsIHJl dCk7Cj4gLQkJCWRlc2MtPmRldi0+ZGVzYyA9IE5VTEw7Cj4gLQkJCXB1dF9kZXZpY2UoJmRlc2Mt PmRldi0+ZGV2KTsKPiAtCQkJZGVzYy0+ZGV2ID0gTlVMTDsKPiAtCQl9Cj4gKwkJbGlzdF9hZGRf dGFpbCgmZGVzYy0+ZGV2LT5ub2RlLCAmaTNjX3VucmVnX2RldnMpOwo+ICsJfQo+ICsKPiArCWkz Y19idXNfbWFpbnRlbmFuY2VfdW5sb2NrKCZtYXN0ZXItPmJ1cyk7Cj4gKwo+ICsJbGlzdF9mb3Jf ZWFjaF9lbnRyeV9zYWZlKGkzY2RldiwgdG1wLCAmaTNjX3VucmVnX2RldnMsIG5vZGUpIHsKPiAr CQlyZXQgPSBkZXZpY2VfcmVnaXN0ZXIoJmkzY2Rldi0+ZGV2KTsKCltTZXZlcml0eTogSGlnaF0K RG9lcyBkcm9wcGluZyB0aGUgbWFpbnRlbmFuY2UgbG9jayBhcm91bmQgZGV2aWNlX3JlZ2lzdGVy KCkgZXhwb3NlCmkzY19kZXZpY2VfdWV2ZW50KCkgYW5kIGRyaXZlciBwcm9iZXMgdG8gYSB1c2Ut YWZ0ZXItZnJlZT8KCklmIGEgY29uY3VycmVudCBJM0MgaG90LWpvaW4gZXZlbnQgb3IgYSBzeXNm cyB3cml0ZSB0byBkb19kYWEgb2NjdXJzIHdoaWxlCmRldmljZV9yZWdpc3RlcigpIGlzIHJ1bm5p bmcgd2l0aG91dCB0aGUgbG9jaywKX19pM2NfbWFzdGVyX2FkZF9pM2NfZGV2X2xvY2tlZCgpIGNv dWxkIGZpbmQgYSBkdXBsaWNhdGUgUElEOgoKX19pM2NfbWFzdGVyX2FkZF9pM2NfZGV2X2xvY2tl ZCgpIHsKICAgICAgICBvbGRkZXYgPSBpM2NfbWFzdGVyX3NlYXJjaF9pM2NfZGV2X2R1cGxpY2F0 ZShuZXdkZXYpOwogICAgICAgIGlmIChvbGRkZXYpIHsKICAgICAgICAgICAgICAgIG5ld2Rldi0+ ZGV2ID0gb2xkZGV2LT5kZXY7CiAgICAgICAgICAgICAgICBpZiAobmV3ZGV2LT5kZXYpCiAgICAg ICAgICAgICAgICAgICAgICAgIG5ld2Rldi0+ZGV2LT5kZXNjID0gbmV3ZGV2OwogICAgICAgICAg ICAgICAgLi4uCiAgICAgICAgICAgICAgICBpM2NfbWFzdGVyX2RldGFjaF9pM2NfZGV2KG9sZGRl dik7CiAgICAgICAgICAgICAgICBpM2NfbWFzdGVyX2ZyZWVfaTNjX2RldihvbGRkZXYpOwogICAg ICAgIH0KfQoKTWVhbndoaWxlLCBkZXZpY2VfcmVnaXN0ZXIoKSB0cmlnZ2VycyBhIEtPQkpfQURE IHVldmVudC4gaTNjX2RldmljZV91ZXZlbnQoKQpyZWFkcyBpM2NkZXYtPmRlc2MgbG9ja2xlc3Ns eToKCmkzY19kZXZpY2VfdWV2ZW50KCkgewogICAgICAgIGlmIChpM2NkZXYtPmRlc2MpCiAgICAg ICAgICAgICAgICBkZXZpbmZvID0gaTNjZGV2LT5kZXNjLT5pbmZvOwp9CgpDb3VsZCB0aGlzIGxl YWQgdG8gaTNjX2RldmljZV91ZXZlbnQoKSBvciBkcml2ZXIgcHJvYmUgZnVuY3Rpb25zIGRlcmVm ZXJlbmNpbmcKdGhlIG9sZCBkZXNjcmlwdG9yIHdoaWxlIGl0IGlzIGJlaW5nIGZyZWVkPwoKPiAr CQlpZiAocmV0KQo+ICsJCQlkZXZfZXJyKCZtYXN0ZXItPmRldiwgIkZhaWxlZCB0byBhZGQgSTND IGRldmljZSAoZXJyID0gJWQpXG4iLCByZXQpOwo+ICsJCWVsc2UKPiArCQkJbGlzdF9kZWxfaW5p dCgmaTNjZGV2LT5ub2RlKTsKPiArCX0KPiArCj4gKwlpM2NfYnVzX21haW50ZW5hbmNlX2xvY2so Jm1hc3Rlci0+YnVzKTsKPiArCj4gKwlsaXN0X2Zvcl9lYWNoX2VudHJ5X3NhZmUoaTNjZGV2LCB0 bXAsICZpM2NfdW5yZWdfZGV2cywgbm9kZSkgewo+ICsJCWxpc3RfZGVsKCZpM2NkZXYtPm5vZGUp Owo+ICsJCWRlc2MgPSBpM2NkZXYtPmRlc2M7Cj4gKwkJaTNjZGV2LT5kZXNjID0gTlVMTDsKCltT ZXZlcml0eTogSGlnaF0KVGhpcyBpcyBhIHByZS1leGlzdGluZyBpc3N1ZSwgYnV0IGRvZXMgc2V0 dGluZyBpM2NkZXYtPmRlc2MgdG8gTlVMTCBiZWZvcmUKdW5yZWdpc3RyYXRpb24gb3IgY2xlYW51 cCBsZWFkIHRvIGxlYWtpbmcgdW5pbml0aWFsaXplZCBzdGFjayBtZW1vcnkgaW4KaTNjX2Rldmlj ZV91ZXZlbnQoKT8KCldoZW4gYSBkZXZpY2UgaXMgdW5yZWdpc3RlcmVkIChvciBpZiByZWdpc3Ry YXRpb24gZmFpbHMgYW5kIHRyaWdnZXJzIGEgdWV2ZW50KSwKaTNjZGV2LT5kZXNjIGlzIHNldCB0 byBOVUxMLiBUaGlzIGJ5cGFzc2VzIHRoZSBpbml0aWFsaXphdGlvbiBvZiBkZXZpbmZvCmluIGkz Y19kZXZpY2VfdWV2ZW50KCk6CgppM2NfZGV2aWNlX3VldmVudCgpIHsKICAgICAgICBzdHJ1Y3Qg aTNjX2RldmljZV9pbmZvIGRldmluZm87CiAgICAgICAgdTE2IG1hbnVmLCBwYXJ0LCBleHQ7Cgog ICAgICAgIGlmIChpM2NkZXYtPmRlc2MpCiAgICAgICAgICAgICAgICBkZXZpbmZvID0gaTNjZGV2 LT5kZXNjLT5pbmZvOwoKICAgICAgICBtYW51ZiA9IEkzQ19QSURfTUFOVUZfSUQoZGV2aW5mby5w aWQpOwogICAgICAgIC4uLgogICAgICAgIHJldHVybiBhZGRfdWV2ZW50X3ZhcihlbnYsICJNT0RB TElBUz1pM2M6ZGNyJTAyWG1hbnVmJTA0WCIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGRldmluZm8uZGNyLCBtYW51Zik7Cn0KClNpbmNlIGRldmluZm8gaXMgdW5pbml0aWFsaXplZCBv biB0aGUgc3RhY2sgd2hlbiBkZXNjIGlzIE5VTEwsIGNvdWxkIHRoaXMKYnJvYWRjYXN0IHVuaW5p dGlhbGl6ZWQga2VybmVsIHN0YWNrIGRhdGEgdG8gdXNlcnNwYWNlIHByb2Nlc3NlcyBsaXN0ZW5p bmcKdG8gbmV0bGluayB1ZXZlbnRzPwoKPiArCQlwdXRfZGV2aWNlKCZpM2NkZXYtPmRldik7Cj4g KwkJZGVzYy0+ZGV2ID0gTlVMTDsKPiAgCX0KPiArCj4gKwlpM2NfYnVzX21haW50ZW5hbmNlX3Vu bG9jaygmbWFzdGVyLT5idXMpOwo+ICB9CgotLSAKU2FzaGlrbyBBSSByZXZpZXcgwrcgaHR0cHM6 Ly9zYXNoaWtvLmRldi8jL3BhdGNoc2V0LzIwMjYwNzI4MTU1MzA4LjE0MjcxMy0xLWFkcmlhbi5o dW50ZXJAaW50ZWwuY29tP3BhcnQ9MQoKLS0gCmxpbnV4LWkzYyBtYWlsaW5nIGxpc3QKbGludXgt aTNjQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1h bi9saXN0aW5mby9saW51eC1pM2MK 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 7C88B376BF2 for ; Tue, 28 Jul 2026 16:19:36 +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=1785255577; cv=none; b=hDjK66oTdXj+s9vy8vA4as5b2lhEsTIPc/hEmrRgsbw5gPIGXV1a9hr66A30kw+MypX3apOhafO5iAFOUnCnbvy9QhlnbEoNgDLpRkv2ZUdSFJkM1dIuhBUNmwPVnQLAZwNDWDHdQtwrwsvVqoLltBEYgHx0Jlj7bd7Qia2jRjY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785255577; c=relaxed/simple; bh=lg5e8qaogR9UM8aFVZmSWy+VfJbmKL0oPMJj5c1nm9Q=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=BeR27txPD3jgxDgiTZPzRTtDTxrpo+4GiQMIkGNT7jHcBfvXOtpTwZz+OXI8JE5gzkNd5n4wSjFZ+3TP78Be3i0Wfs5pbFIbvWOewjOwlBSrF8Lz2LYfkBlq5l/oDTy4jBt86pnL3b3SG8K4DGlw4jgVCC61eSOBUSNauuy8fWo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Y0btHdfk; 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="Y0btHdfk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C236F1F00A3A; Tue, 28 Jul 2026 16:19:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785255576; bh=peruRkkKr+azNeAOQhOqjTEeC5FtrRlabTA5htTlFOA=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=Y0btHdfkjwL0gzq1s0PqOUlY3CsPtTmtOLrqnw40pBVKMez5Da3ejoxhhVOi/YneM OZcFINxFN4zwqGrSmMyVZznJ/MQ7iiiz3FWS1fW8dCZCwEmPLNbDXkN1300v2F9/6Q JbPhVMBJBnQ74ixqAqT9Nor30B3Agc3ehgtokogzqjI/BpkS903Zo870PgRdUPIclS VQNIx9UIvbJ46L6E0tdJuSVdd0zgy0i0citZsEZJSC8UGTyFufRI6ce/rdY1qrXP8E fb85w4TH6HsGur7q7i3nN9ZDEVK2FJwxwUFrWEJSgKBTpmgcntTbUyiatUImQLrEwh ICCovjhC9mQVw== From: sashiko-bot@kernel.org Subject: Re: [PATCH V2 1/8] i3c: master: Fix recursive locking during device registration Reply-To: sashiko-reviews@lists.linux.dev To: "Adrian Hunter" Cc: Frank.Li@kernel.org, linux-pci@vger.kernel.org, linux-i3c@lists.infradead.org, "Alexandre Belloni" In-Reply-To: <20260728155308.142713-2-adrian.hunter@intel.com> References: <20260728155308.142713-1-adrian.hunter@intel.com> <20260728155308.142713-2-adrian.hunter@intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jul 2026 16:19:35 +0000 Message-Id: <20260728161935.C236F1F00A3A@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= i3c_device_uevent() and driver probe functions to a Use-After-Free if a co= ncurrent DAA replaces the device. Pre-existing issues: - [High] i3c_device_uevent() leaks uninitialized stack memory to userspace = when i3cdev->desc is NULL. -- --- Patch [1]: [PATCH V2 1/8] i3c: master: Fix recursive locking during dev= ice registration --- commit 33a4dcd6c5626faef95bc7cd02ec4c56c6710c78 Author: Adrian Hunter i3c: master: Fix recursive locking during device registration This commit separates device creation from registration to fix a recursive locking issue. It drops the bus maintenance lock around device_register() to prevent deadlocks when probe callbacks invoke I3C helpers. diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c index fd3e79d10c840..874f6e11b296d 100644 --- a/drivers/i3c/master.c +++ b/drivers/i3c/master.c [ ... ] > @@ -1999,25 +2008,37 @@ i3c_master_register_new_i3c_devs(struct i3c_maste= r_controller *master) > if (desc->boardinfo) > desc->dev->dev.of_node =3D desc->boardinfo->of_node; > =20 > - ret =3D device_register(&desc->dev->dev); > - if (ret) { > - dev_err(&master->dev, > - "Failed to add I3C device (err =3D %d)\n", ret); > - desc->dev->desc =3D NULL; > - put_device(&desc->dev->dev); > - desc->dev =3D NULL; > - } > + 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 maintenance lock around device_register() expose i3c_device_uevent() and driver probes to a use-after-free? If a concurrent I3C hot-join event or a sysfs write to do_daa occurs while device_register() is running without the lock, __i3c_master_add_i3c_dev_locked() could find a duplicate PID: __i3c_master_add_i3c_dev_locked() { olddev =3D i3c_master_search_i3c_dev_duplicate(newdev); if (olddev) { newdev->dev =3D olddev->dev; if (newdev->dev) newdev->dev->desc =3D newdev; ... i3c_master_detach_i3c_dev(olddev); i3c_master_free_i3c_dev(olddev); } } Meanwhile, device_register() triggers a KOBJ_ADD uevent. i3c_device_uevent() reads i3cdev->desc locklessly: i3c_device_uevent() { if (i3cdev->desc) devinfo =3D i3cdev->desc->info; } Could this lead to i3c_device_uevent() or driver probe functions dereferenc= ing the old descriptor while it is being freed? > + 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; [Severity: High] This is a pre-existing issue, but does setting i3cdev->desc to NULL before unregistration or cleanup lead to leaking uninitialized stack memory in i3c_device_uevent()? When a device is unregistered (or if registration fails and triggers a ueve= nt), i3cdev->desc is set to NULL. This bypasses the initialization of devinfo in i3c_device_uevent(): i3c_device_uevent() { struct i3c_device_info devinfo; u16 manuf, part, ext; if (i3cdev->desc) devinfo =3D i3cdev->desc->info; manuf =3D I3C_PID_MANUF_ID(devinfo.pid); ... return add_uevent_var(env, "MODALIAS=3Di3c:dcr%02Xmanuf%04X", devinfo.dcr, manuf); } Since devinfo is uninitialized on the stack when desc is NULL, could this broadcast uninitialized kernel stack data to userspace processes listening to netlink uevents? > + put_device(&i3cdev->dev); > + desc->dev =3D NULL; > } > + > + i3c_bus_maintenance_unlock(&master->bus); > } --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260728155308.1427= 13-1-adrian.hunter@intel.com?part=3D1