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 801EFC43458 for ; Tue, 14 Jul 2026 10:20:29 +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=zEnqCx9yBlMrWOlc9nPs4Jrive2DiYJbHop3FrxO114=; b=gxCatx+1P/ry2m K1pGDq2wEL43Jg3w3JVr6fY6TOVoFEqWjdxqShep6l+MGLG766paVIcBZdKfqotRl2z7N6MB6Tv60 FOHOvxxMxMeDKae8NxISUdk9Fw/WUM4UtRWHpB4FsLS09E89jMw2HRAUbh+3l9Vk+44VeGFOYhr8p KTku5/D+dGDRTIMRDxlwXshNUupsaVTEPN4eFpWoN/Y3d4/Kstd49EPgcx2+HzAjChCfn2vSHdUtY X8UNIGk8edtDxnuT3fcJjSoJgSn84Uzm1jqqC4yfFLmnw+xq8oelCO67xS7/yR1qST+AZyglN9pWl N+hb20OtsFwRTNgmm9dA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjaFY-0000000BYJ9-3RHp; Tue, 14 Jul 2026 10:20:29 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjaFX-0000000BYIk-40em for linux-i3c@lists.infradead.org; Tue, 14 Jul 2026 10:20:28 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 0288460120; Tue, 14 Jul 2026 10:20:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 510E01F000E9; Tue, 14 Jul 2026 10:20:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784024426; bh=ZScVYZ8poWtq8BGB0ii8vZJEoswk2dbw3WrnJPdkMG0=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=ZyheAOxJBZurZud2IyFgu8KQj4mcBPs/u2kQ/vtZqCNngePbypIA9hCsH7jXUUQ9B q+y0YgtFl84czVDT2FageQ78ghJDjmG9NVk/fAbIA/XNTmRwFfa/MEPOwrYPXeqi6y 7UijBnFhPJ41M2ccDfaRflMX0noLFlKA+FZdmg5VCL/H4uEFMdOwRxo0IgCOlu/Zjj B2ptrVBqxVMBIUabN8MZVzg/QWBkiF73vOr0A4PjUxt0dSHriZyVzEYuYbLYc8n3pO 1Dn8LEYcLJyFGmshY4d8y/VLh8YOq5SI0xGOD+kDcferr2e6JMpI1kRgCdEctKykoP GK3/DUj41GDog== From: sashiko-bot@kernel.org Subject: Re: [PATCH v14 2/8] i3c: master: Fix IBI request and free cleanup paths To: "Lakshay Piplani" Cc: conor+dt@kernel.org, linux-i3c@lists.infradead.org, "Alexandre Belloni" , robh@kernel.org, Frank.Li@kernel.org, devicetree@vger.kernel.org In-Reply-To: <20260714092053.2461482-3-lakshay.piplani@nxp.com> References: <20260714092053.2461482-1-lakshay.piplani@nxp.com> <20260714092053.2461482-3-lakshay.piplani@nxp.com> Date: Tue, 14 Jul 2026 10:20:25 +0000 Message-Id: <20260714102026.510E01F000E9@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 MiBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtIaWdoXSBC eXBhc3NpbmcgdGhlIGNvcmUgY2xlYW51cCBwYXRocyB3aGVuIGBkZXYtPmliaWAgaXMgY2xlYXJl ZCBieSBhIGNvbnRyb2xsZXIgY2FsbGJhY2sgY2F1c2VzIGEgcGVybWFuZW50IGxlYWsgb2YgdGhl IElCSSB3b3JrcXVldWUgKGluY2x1ZGluZyBpdHMgcmVzY3VlciBrdGhyZWFkKSBhbmQgcG90ZW50 aWFsbHkgdGhlIGBpYmlgIG9iamVjdCBpdHNlbGYuCgpQcmUtZXhpc3RpbmcgaXNzdWVzOgotIFtI aWdoXSBQb3RlbnRpYWwgdXNlLWFmdGVyLWZyZWUgb2YgSUJJIHBvb2wgZHVyaW5nIHdvcmtxdWV1 ZSBkZXN0cnVjdGlvbiBpZiBJQkkgZGlzYWJsZSBmYWlscy4KLS0KCi0tLSBQYXRjaCBbMl06IFtQ QVRDSCB2MTQgMi84XSBpM2M6IG1hc3RlcjogRml4IElCSSByZXF1ZXN0IGFuZCBmcmVlIGNsZWFu dXAgcGF0aHMgLS0tCmNvbW1pdCBlMGQxYzU3ZDI5MjRmNjY4OThhNDAyMzJmN2U1MmNhMGUxYmUw YWVhCkF1dGhvcjogTGFrc2hheSBQaXBsYW5pIDxsYWtzaGF5LnBpcGxhbmlAbnhwLmNvbT4KCmkz YzogbWFzdGVyOiBGaXggSUJJIHJlcXVlc3QgYW5kIGZyZWUgY2xlYW51cCBwYXRocwoKVGhpcyBj b21taXQgYXR0ZW1wdHMgdG8gZml4IGEgd29ya3F1ZXVlIGxlYWsgaW4gdGhlIElCSSByZXF1ZXN0 IGZhaWx1cmUgcGF0aApieSBkZXN0cm95aW5nIHRoZSB3b3JrcXVldWUgYmVmb3JlIGZyZWVpbmcg dGhlIElCSSBvYmplY3QuIEl0IGFsc28gYWRkcyBjaGVja3MKdG8gYXZvaWQgdG91Y2hpbmcgZGV2 LT5pYmkgYWZ0ZXIgY29udHJvbGxlciBjYWxsYmFja3MgaWYgdGhleSBoYXZlIGFscmVhZHkKY2xl YXJlZCBpdCwgYWltaW5nIHRvIHByZXZlbnQgTlVMTCBwb2ludGVyIGRlcmVmZXJlbmNlcy4KCj4g ZGlmZiAtLWdpdCBhL2RyaXZlcnMvaTNjL21hc3Rlci5jIGIvZHJpdmVycy9pM2MvbWFzdGVyLmMK PiBpbmRleCAzYjFjMzQyYmUyYmM1Li5iYTM3ZjcxYmFkYWM4IDEwMDY0NAo+IC0tLSBhL2RyaXZl cnMvaTNjL21hc3Rlci5jCj4gKysrIGIvZHJpdmVycy9pM2MvbWFzdGVyLmMKPiBAQCAtMzcwMiw4 ICszNzAyLDE4IEBAIGludCBpM2NfZGV2X3JlcXVlc3RfaWJpX2xvY2tlZChzdHJ1Y3QgaTNjX2Rl dl9kZXNjICpkZXYsCj4gIAo+ICAJZGV2LT5pYmkgPSBpYmk7Cj4gIAlyZXQgPSBtYXN0ZXItPm9w cy0+cmVxdWVzdF9pYmkoZGV2LCByZXEpOwo+IC0JaWYgKHJldCkgewo+IC0JCWtmcmVlKGliaSk7 Cj4gKwo+ICsJLyoKPiArCSAqIFRoZSBjb250cm9sbGVyIGNhbGxiYWNrIG1heSBoYXZlIGFscmVh ZHkgcmVsZWFzZWQgYW5kIGNsZWFyZWQgZGV2LT5pYmkKPiArCSAqIHdoZW4gdGhlIHJlcXVlc3Qg aXMgZm9yd2FyZGVkIGJ5IGEgdmlydHVhbCBjb250cm9sbGVyLiBPbmx5IGNsZWFuIHVwIHRoZQo+ ICsJICogSUJJIG9iamVjdCBpZiB0aGUgY2FsbGJhY2sgbGVmdCBkZXYtPmliaSB2YWxpZC4KPiAr CSAqLwo+ICsJaWYgKHJldCAmJiBkZXYtPmliaSkgewo+ICsJCS8qIEF2b2lkIGxlYWtpbmcgdGhl IHdvcmtxdWV1ZSBhbGxvY2F0ZWQgZm9yIHRoaXMgSUJJIHJlcXVlc3QuICovCj4gKwkJaWYgKGRl di0+aWJpLT53cSkKPiArCQkJZGVzdHJveV93b3JrcXVldWUoZGV2LT5pYmktPndxKTsKPiArCj4g KwkJa2ZyZWUoZGV2LT5pYmkpOwo+ICAJCWRldi0+aWJpID0gTlVMTDsKPiAgCX0KCltTZXZlcml0 eTogSGlnaF0KRG9lcyB0aGlzIGxvZ2ljIGludHJvZHVjZSBhIHBlcm1hbmVudCBsZWFrIG9mIHRo ZSBJQkkgd29ya3F1ZXVlIGFuZCB0aGUgbG9jYWwKaWJpIG9iamVjdD8KClNpbmNlIHRoZSBjb3Jl IGZyYW1ld29yayBkeW5hbWljYWxseSBhbGxvY2F0ZWQgaWJpIGFuZCBpYmktPndxIGVhcmxpZXIg aW4KaTNjX2Rldl9yZXF1ZXN0X2liaV9sb2NrZWQoKSwgaWYgbWFzdGVyLT5vcHMtPnJlcXVlc3Rf aWJpKCkgZmFpbHMgYW5kIHRoZQpjYWxsYmFjayBjbGVhcmVkIGRldi0+aWJpLCB0aGUgY2hlY2sg aWYgKHJldCAmJiBkZXYtPmliaSkgd2lsbCBiZSBmYWxzZS4KCkJlY2F1c2UgdGhlIGNhbGxiYWNr IGRvZXMgbm90IG93biB0aGVzZSByZXNvdXJjZXMgYW5kIGNhbm5vdCBzYWZlbHkgZGVzdHJveQp0 aGUgZnJhbWV3b3JrJ3Mgd29ya3F1ZXVlLCB0aGUgd29ya3F1ZXVlIChpbmNsdWRpbmcgaXRzIHJl c2N1ZXIga3RocmVhZCkgYW5kCnRoZSBpYmkgb2JqZWN0IHdpbGwgYmUgc2tpcHBlZCBkdXJpbmcg Y2xlYW51cCBhbmQgbGVhayBwZXJtYW5lbnRseS4KClsgLi4uIF0KCj4gQEAgLTM3NDMsNiArMzc1 MywxMyBAQCB2b2lkIGkzY19kZXZfZnJlZV9pYmlfbG9ja2VkKHN0cnVjdCBpM2NfZGV2X2Rlc2Mg KmRldikKPiAgCj4gIAltYXN0ZXItPm9wcy0+ZnJlZV9pYmkoZGV2KTsKCltTZXZlcml0eTogSGln aF0KVGhpcyBpc24ndCBhIGJ1ZyBpbnRyb2R1Y2VkIGJ5IHRoaXMgcGF0Y2gsIGJ1dCBjYW4gdGhp cyBsZWFkIHRvIGEKdXNlLWFmdGVyLWZyZWUgb2YgdGhlIElCSSBwb29sIG1lbW9yeSBpZiBkaXNh YmxpbmcgdGhlIElCSSBmYWlscz8KCkVhcmxpZXIgaW4gaTNjX2Rldl9mcmVlX2liaV9sb2NrZWQo KSwgaWYgdGhlIElCSSBpcyBzdGlsbCBlbmFibGVkLCBpdCB0cmllcwp0byBkaXNhYmxlIGl0IHZp YSBpM2NfZGV2X2Rpc2FibGVfaWJpX2xvY2tlZCgpLiBJZiB0aGF0IGRpc2FibGUgZmFpbHMKKGUu Zy4sIGR1ZSB0byBhIGhhcmR3YXJlIHRpbWVvdXQpLCBpdCByZXR1cm5zIGFuIGVycm9yIHdpdGhv dXQgd2FpdGluZyBmb3IKcGVuZGluZyBJQklzIHRvIGZpbmlzaCwgYW5kIHdlIHByb2NlZWQgZGly ZWN0bHkgdG8gbWFzdGVyLT5vcHMtPmZyZWVfaWJpKGRldikuCgpUaGlzIGNhbGxiYWNrIGltbWVk aWF0ZWx5IGZyZWVzIHRoZSBnZW5lcmljIElCSSBwb29sLiBTdWJzZXF1ZW50bHksCmRlc3Ryb3lf d29ya3F1ZXVlKCkgaXMgY2FsbGVkIGJlbG93LCB3aGljaCBzeW5jaHJvbm91c2x5IGRyYWlucwph bnkgZXhlY3V0aW5nIElCSSBoYW5kbGVyIHdvcmtzLiBTaW5jZSB0aGVzZSBwZW5kaW5nIHdvcmsg aXRlbXMgcmVzaWRlIGluc2lkZQp0aGUgbmV3bHktZnJlZWQgcG9vbCwgd29uJ3QgdGhlIHJlc2N1 ZXIgdGhyZWFkIGRlcmVmZXJlbmNlIGZyZWVkIG1lbW9yeSBhcwp0aGUgd29ya3F1ZXVlIGRyYWlu cz8KCj4gKwkvKgo+ICsJICogVGhlIGNvbnRyb2xsZXIgY2FsbGJhY2sgbWF5IGhhdmUgYWxyZWFk eSByZWxlYXNlZCBkZXYtPmliaSwgZm9yIGV4YW1wbGUKPiArCSAqIHdoZW4gdGhlIHJlcXVlc3Qg d2FzIGZvcndhcmRlZCBieSBhIHZpcnR1YWwgY29udHJvbGxlci4KPiArCSAqLwo+ICsJaWYgKCFk ZXYtPmliaSkKPiArCQlyZXR1cm47CgpbU2V2ZXJpdHk6IEhpZ2hdClNpbWlsYXIgdG8gdGhlIHJl cXVlc3QgcGF0aCBhYm92ZSwgZG9lcyB0aGlzIGVhcmx5IHJldHVybiBieXBhc3MgdGhlCmRlc3Ry dWN0aW9uIG9mIHRoZSB3b3JrcXVldWUgYW5kIGNhdXNlIGEgcmVzb3VyY2UgbGVhaz8KCklmIHRo ZSBjb250cm9sbGVyIGNhbGxiYWNrIGNsZWFyZWQgZGV2LT5pYmkgb24gdGhlIGZyZWUgcGF0aCwg d2UgcmV0dXJuCmVhcmx5IGFuZCBza2lwIHRoZSBkZXN0cm95X3dvcmtxdWV1ZShkZXYtPmliaS0+ d3EpIHN0ZXAsIGxlYWtpbmcgdGhlCndvcmtxdWV1ZSBhbmQgaXRzIHJlc2N1ZXIgdGhyZWFkLgoK PiArCj4gIAlpZiAoZGV2LT5pYmktPndxKSB7Cj4gIAkJZGVzdHJveV93b3JrcXVldWUoZGV2LT5p YmktPndxKTsKPiAgCQlkZXYtPmliaS0+d3EgPSBOVUxMOwoKLS0gClNhc2hpa28gQUkgcmV2aWV3 IMK3IGh0dHBzOi8vc2FzaGlrby5kZXYvIy9wYXRjaHNldC8yMDI2MDcxNDA5MjA1My4yNDYxNDgy LTEtbGFrc2hheS5waXBsYW5pQG54cC5jb20/cGFydD0yCgotLSAKbGludXgtaTNjIG1haWxpbmcg bGlzdApsaW51eC1pM2NAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWkzYwo= 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 F0051365A03 for ; Tue, 14 Jul 2026 10:20:26 +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=1784024428; cv=none; b=m/HVsE5tU5z950jB0RvlVmUPS17Jzns+D7mfOBDO/Jperq2+BMwSpVxXuXZLIYcGRdj3P4EuUuAnrzFztHX/u4pbdZLX4wKvTJacG2F8PsuLkxJ1TlQz7DX9zBOqLaoYBEMxpj/vha4hNIGoXChxRmiqyT8KXJhDjCrr6kW7SIg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784024428; c=relaxed/simple; bh=3+1nwTN8YOP3de9oonqsCDwxOdz0GnaNE6/DZBRFy14=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=lfRITu5bUbCG3CJiuNU/5m8KPYGH+btuBYd0k0ypnTEOZdc/fVdiOM+q9aqU8JJdHSoTz2LhqVq4siJP3TH0vDaa1uoXzDZMqdsMqXad5gRyHQ5Q0rAGz/gwTDA3DdzrUpf0XrxV9UAAkEM6cRI7IHGRrrO48bR3ne0G3I91OUg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZyheAOxJ; 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="ZyheAOxJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 510E01F000E9; Tue, 14 Jul 2026 10:20:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784024426; bh=ZScVYZ8poWtq8BGB0ii8vZJEoswk2dbw3WrnJPdkMG0=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=ZyheAOxJBZurZud2IyFgu8KQj4mcBPs/u2kQ/vtZqCNngePbypIA9hCsH7jXUUQ9B q+y0YgtFl84czVDT2FageQ78ghJDjmG9NVk/fAbIA/XNTmRwFfa/MEPOwrYPXeqi6y 7UijBnFhPJ41M2ccDfaRflMX0noLFlKA+FZdmg5VCL/H4uEFMdOwRxo0IgCOlu/Zjj B2ptrVBqxVMBIUabN8MZVzg/QWBkiF73vOr0A4PjUxt0dSHriZyVzEYuYbLYc8n3pO 1Dn8LEYcLJyFGmshY4d8y/VLh8YOq5SI0xGOD+kDcferr2e6JMpI1kRgCdEctKykoP GK3/DUj41GDog== From: sashiko-bot@kernel.org Subject: Re: [PATCH v14 2/8] i3c: master: Fix IBI request and free cleanup paths Reply-To: sashiko-reviews@lists.linux.dev To: "Lakshay Piplani" Cc: conor+dt@kernel.org, linux-i3c@lists.infradead.org, "Alexandre Belloni" , robh@kernel.org, Frank.Li@kernel.org, devicetree@vger.kernel.org In-Reply-To: <20260714092053.2461482-3-lakshay.piplani@nxp.com> References: <20260714092053.2461482-1-lakshay.piplani@nxp.com> <20260714092053.2461482-3-lakshay.piplani@nxp.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jul 2026 10:20:25 +0000 Message-Id: <20260714102026.510E01F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: devicetree@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] Bypassing the core cleanup paths when `dev->ibi` is cleared by a c= ontroller callback causes a permanent leak of the IBI workqueue (including = its rescuer kthread) and potentially the `ibi` object itself. Pre-existing issues: - [High] Potential use-after-free of IBI pool during workqueue destruction = if IBI disable fails. -- --- Patch [2]: [PATCH v14 2/8] i3c: master: Fix IBI request and free cleanu= p paths --- commit e0d1c57d2924f66898a40232f7e52ca0e1be0aea Author: Lakshay Piplani i3c: master: Fix IBI request and free cleanup paths This commit attempts to fix a workqueue leak in the IBI request failure path by destroying the workqueue before freeing the IBI object. It also adds che= cks to avoid touching dev->ibi after controller callbacks if they have already cleared it, aiming to prevent NULL pointer dereferences. > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c > index 3b1c342be2bc5..ba37f71badac8 100644 > --- a/drivers/i3c/master.c > +++ b/drivers/i3c/master.c > @@ -3702,8 +3702,18 @@ int i3c_dev_request_ibi_locked(struct i3c_dev_desc= *dev, > =20 > dev->ibi =3D ibi; > ret =3D master->ops->request_ibi(dev, req); > - if (ret) { > - kfree(ibi); > + > + /* > + * The controller callback may have already released and cleared dev->i= bi > + * when the request is forwarded by a virtual controller. Only clean up= the > + * IBI object if the callback left dev->ibi valid. > + */ > + if (ret && dev->ibi) { > + /* Avoid leaking the workqueue allocated for this IBI request. */ > + if (dev->ibi->wq) > + destroy_workqueue(dev->ibi->wq); > + > + kfree(dev->ibi); > dev->ibi =3D NULL; > } [Severity: High] Does this logic introduce a permanent leak of the IBI workqueue and the loc= al ibi object? Since the core framework dynamically allocated ibi and ibi->wq earlier in i3c_dev_request_ibi_locked(), if master->ops->request_ibi() fails and the callback cleared dev->ibi, the check if (ret && dev->ibi) will be false. Because the callback does not own these resources and cannot safely destroy the framework's workqueue, the workqueue (including its rescuer kthread) and the ibi object will be skipped during cleanup and leak permanently. [ ... ] > @@ -3743,6 +3753,13 @@ void i3c_dev_free_ibi_locked(struct i3c_dev_desc *= dev) > =20 > master->ops->free_ibi(dev); [Severity: High] This isn't a bug introduced by this patch, but can this lead to a use-after-free of the IBI pool memory if disabling the IBI fails? Earlier in i3c_dev_free_ibi_locked(), if the IBI is still enabled, it tries to disable it via i3c_dev_disable_ibi_locked(). If that disable fails (e.g., due to a hardware timeout), it returns an error without waiting for pending IBIs to finish, and we proceed directly to master->ops->free_ibi(de= v). This callback immediately frees the generic IBI pool. Subsequently, destroy_workqueue() is called below, which synchronously drains any executing IBI handler works. Since these pending work items reside insi= de the newly-freed pool, won't the rescuer thread dereference freed memory as the workqueue drains? > + /* > + * The controller callback may have already released dev->ibi, for exam= ple > + * when the request was forwarded by a virtual controller. > + */ > + if (!dev->ibi) > + return; [Severity: High] Similar to the request path above, does this early return bypass the destruction of the workqueue and cause a resource leak? If the controller callback cleared dev->ibi on the free path, we return early and skip the destroy_workqueue(dev->ibi->wq) step, leaking the workqueue and its rescuer thread. > + > if (dev->ibi->wq) { > destroy_workqueue(dev->ibi->wq); > dev->ibi->wq =3D NULL; --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260714092053.2461= 482-1-lakshay.piplani@nxp.com?part=3D2