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 7AD80C43458 for ; Sat, 4 Jul 2026 07:49:11 +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=ldNTcxZ0QUsopdJxxl6HU9QQx9xL0TEYQ4GKr9gF3Us=; b=N3O4mEByfmmB/8 uB9mcA5/VvvBgxjR4/sbOPkyTS9/YqeE3uCgyXenQuZYDTzvnOuVUXaBl8NL11Fy1tVd+4JHmQxkE gZcg/3MMNwt3YILckqXKT01OOew0vPNY23ZHlq/oleZXP2VKlWJkIbMCtXLDaNAI+mbmM3kJYj59i bTppC3Fxj6RcaykFfvChqvhb2AoV6y8sv9h0D9jCAqibkWKGqC9og5D/hF9cazkaa5tT/s6FovQft QaydzJRhJwstcjefEkCJda/zMLgdQzx/1QaU6riKrgCPKQ7q7WBIN/YIZKnXzeIHkOEynBljfS8om OLJCniE023/7AA9U1/hQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wfv7f-00000008Gyl-0qOs; Sat, 04 Jul 2026 07:49:11 +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 1wfv7d-00000008Gye-3ze9 for linux-phy@lists.infradead.org; Sat, 04 Jul 2026 07:49:10 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id EF6A260052; Sat, 4 Jul 2026 07:49:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D0471F00A3A; Sat, 4 Jul 2026 07:49:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783151348; bh=3xjteroih40a3MfOMXhUMF5dbo99yBBa1fmVNc6A6go=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=UiH2Ht1FuWLciuKlQGUrZNotQ7JUh85tgwL5nYQFoK2d8nq28Kt2WWFQ9nLsnHglq nS5jM6vQ9iP6LyTz3T+uwAcbSoS16H0nl9BSlSv6+p7K/msMpeGUFvQV7S8m1puE87 4dHI08eHGNGTk0CIkGhJp6rzdJjl8AzDhmJyaI0xIgd8XKJyB46ddLsqTW0Um7359/ mPHcbojv7TcAh79WmZsnTUmjf4atWnm+GMTDgmBL0PCZBjPAAosav0re0TF0WPjqF2 CP9nEC+ybhAuB5kdfLAjLca0Ssmh9bqYiMVgPsghWxKohElvjGYn1pEKarN5Pd3MJN DOBizT0qvW5+A== From: sashiko-bot@kernel.org Subject: Re: [PATCH 1/5] phy: cpcap-usb: Prevent line glitches from triggering sysrq To: "Ivaylo Dimitrov" Cc: vkoul@kernel.org, linux-phy@lists.infradead.org, devicetree@vger.kernel.org, conor+dt@kernel.org, neil.armstrong@linaro.org, olteanv@gmail.com, robh@kernel.org In-Reply-To: <20260704073843.1750458-2-ivo.g.dimitrov.75@gmail.com> References: <20260704073843.1750458-1-ivo.g.dimitrov.75@gmail.com> <20260704073843.1750458-2-ivo.g.dimitrov.75@gmail.com> Date: Sat, 04 Jul 2026 07:49:07 +0000 Message-Id: <20260704074908.3D0471F00A3A@smtp.kernel.org> X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list 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-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg NSBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtIaWdoXSBU aGUgZ2xvYmFsIFN5c1JxIHN1cHBvcnQgbWFzayBpcyBwZXJtYW5lbnRseSBhbHRlcmVkIGlmIGFu IGVycm9yIG9jY3VycyBkdXJpbmcgVUFSVCBtb2RlIGNvbmZpZ3VyYXRpb24uCi0gW0hpZ2hdIEZs YXdlZCBiaXR3aXNlIGxvZ2ljIGZhaWxzIHRvIGVmZmVjdGl2ZWx5IGRpc2FibGUgU3lzUnEgaW4g c3lzdGVtIGNvbmZpZ3VyYXRpb25zIHRoYXQgdXNlIHNwZWNpZmljIGZlYXR1cmUgbWFza3MsIGxl YXZpbmcgdGhlIHN5c3RlbSB2dWxuZXJhYmxlIHRvIGdsaXRjaGVzLgotIFtIaWdoXSBUaGUgZHJp dmVyIG1vZGlmaWVzIGdsb2JhbCBzeXN0ZW0gY29uZmlndXJhdGlvbiB0byBtYXNrIGEgbG9jYWwg aGFyZHdhcmUgZ2xpdGNoLCBpbnRyb2R1Y2luZyBzeXN0ZW0td2lkZSBzaWRlIGVmZmVjdHMgYW5k IHJhY2UgY29uZGl0aW9ucy4KClByZS1leGlzdGluZyBpc3N1ZXM6Ci0gW0hpZ2hdIEEgVXNlLUFm dGVyLUZyZWUgdnVsbmVyYWJpbGl0eSBleGlzdHMgYmVjYXVzZSBkZXZyZXMtbWFuYWdlZCBJUlFz IGNhbiBxdWV1ZSBkZWxheWVkIHdvcmsgb24gZnJlZWQgbWVtb3J5IGFmdGVyIGByZW1vdmUoKWAg Y29tcGxldGVzLgotIFtIaWdoXSBIYXJkd2FyZSB0ZWFyZG93biBpbiBgcmVtb3ZlKClgIHJhY2Vz IHdpdGggdGhlIGJhY2tncm91bmQgd29ya2VyLCBsZWFkaW5nIHRvIHVuZGVmaW5lZCBoYXJkd2Fy ZSBzdGF0ZS4KLS0KCmNvbW1pdCBkODllMTAyMjVmNzBiYzI3NzFmN2Q5OTZkZWNiNDI5MjBkMzJm ZTg4CkF1dGhvcjogVG9ueSBMaW5kZ3JlbiA8dG9ueUBhdG9taWRlLmNvbT4KCnBoeTogY3BjYXAt dXNiOiBQcmV2ZW50IGxpbmUgZ2xpdGNoZXMgZnJvbSB0cmlnZ2VyaW5nIHN5c3JxCgpUaGlzIGNv bW1pdCBhdHRlbXB0cyB0byBwcmV2ZW50IHJhbmRvbSBzeXNycSBldmVudHMgd2hlbiBzd2l0Y2hp bmcgZnJvbSBVU0IKdG8gZGVidWcgc2VyaWFsIHBvcnQgbW9kZS4gSXQgdGVtcG9yYXJpbHkgZGlz YWJsZXMgc3lzcnEgZHVyaW5nIG1vZGUgY2hhbmdlcwp0byBtYXNrIGxpbmUgZ2xpdGNoZXMuCgo+ IGRpZmYgLS1naXQgYS9kcml2ZXJzL3BoeS9tb3Rvcm9sYS9waHktY3BjYXAtdXNiLmMgYi9kcml2 ZXJzL3BoeS9tb3Rvcm9sYS9waHktY3BjYXAtdXNiLmMKPiAtLS0gYS9kcml2ZXJzL3BoeS9tb3Rv cm9sYS9waHktY3BjYXAtdXNiLmMKPiArKysgYi9kcml2ZXJzL3BoeS9tb3Rvcm9sYS9waHktY3Bj YXAtdXNiLmMKClsgLi4uIF0KCj4gQEAgLTQxMyw3ICs0MTQsMTIgQEAgc3RhdGljIGludCBjcGNh cF91c2JfZ3Bpb19zZXRfbW9kZShzdHJ1Y3QgY3BjYXBfcGh5X2RkYXRhICpkZGF0YSwKPiAgCj4g IHN0YXRpYyBpbnQgY3BjYXBfdXNiX3NldF91YXJ0X21vZGUoc3RydWN0IGNwY2FwX3BoeV9kZGF0 YSAqZGRhdGEpCj4gIHsKPiAtCWludCBlcnJvcjsKPiArCWludCBzeXNycSwgZXJyb3I7Cj4gKwo+ ICsJLyogRGlzYWJsZSBzeXNycSB0byBwcmV2ZW50IHJhbmRvbSBzeXNycSBldmVudHMgb24gbGlu ZSBnbGl0Y2hlcyAqLwo+ICsJc3lzcnEgPSBzeXNycV9tYXNrKCk7Cj4gKwlpZiAoc3lzcnEgJiAx KQo+ICsJCXN5c3JxX3RvZ2dsZV9zdXBwb3J0KHN5c3JxICYgfjEpOwoKW1NldmVyaXR5OiBIaWdo XQpEb2VzIG1vZGlmeWluZyB0aGUgZ2xvYmFsIHN5c3JxIHN0YXRlIGhlcmUgY3JlYXRlIGEgcmFj ZSBjb25kaXRpb24/CgpJZiBhbiBhZG1pbmlzdHJhdG9yIGNvbmN1cnJlbnRseSBtb2RpZmllcyB0 aGUgc3lzcnEgc2V0dGluZ3MgdmlhCi9wcm9jL3N5cy9rZXJuZWwvc3lzcnEsIHdpbGwgdGhlIHJl c3RvcmF0aW9uIGNhbGwgYXQgdGhlIGVuZCBvZiB0aGlzCmZ1bmN0aW9uIGJsaW5kbHkgb3Zlcndy aXRlIHRoZWlyIG5ldyBzdGF0ZT8KCltTZXZlcml0eTogSGlnaF0KV2lsbCB0aGlzIGNvcnJlY3Rs eSBkaXNhYmxlIHN5c3JxIGlmIHRoZSBzeXN0ZW0gaXMgY29uZmlndXJlZCB3aXRoIGEKc3BlY2lm aWMgZmVhdHVyZSBtYXNrPwoKSWYgdGhlIGFkbWluaXN0cmF0b3IgY2xlYXJzIHRoZSBTWVNSUV9F TkFCTEVfQUxMIGJpdCAoYml0IDApIGJ1dCBsZWF2ZXMKb3RoZXIgZmVhdHVyZXMgZW5hYmxlZCwg c3lzcnEgJiAxIGV2YWx1YXRlcyB0byAwLCBieXBhc3NpbmcgdGhlIGRpc2FibGVtZW50LgoKSWYg Yml0IDAgYW5kIG90aGVyIGJpdHMgYXJlIHNldCwgc3lzcnEgJiB+MSBkaXNhYmxlcyB0aGUgJ2Vu YWJsZSBhbGwnIGZsYWcKYnV0IGxlYXZlcyB0aGUgc3BlY2lmaWMgbG9nZ2luZy9kdW1waW5nIGZl YXR1cmVzIGFjdGl2ZWx5IGVuYWJsZWQuCgpbIC4uLiBdCgo+IEBAIC00NDgsNiArNDU0LDkgQEAg c3RhdGljIGludCBjcGNhcF91c2Jfc2V0X3VhcnRfbW9kZShzdHJ1Y3QgY3BjYXBfcGh5X2RkYXRh ICpkZGF0YSkKPiAgCWlmIChlcnJvcikKPiAgCQlnb3RvIG91dF9lcnI7Cj4gIAo+ICsJaWYgKHN5 c3JxICYgMSkKPiArCQlzeXNycV90b2dnbGVfc3VwcG9ydChzeXNycSk7Cj4gKwo+ICAJcmV0dXJu IDA7Cj4gIAo+ICBvdXRfZXJyOgoKW1NldmVyaXR5OiBIaWdoXQpEb2VzIHRoaXMgZXJyb3IgcGF0 aCBwZXJtYW5lbnRseSBhbHRlciB0aGUgc3lzcnEgc3VwcG9ydCBtYXNrPwoKSWYgYSBmYWlsdXJl IG9jY3VycyBkdXJpbmcgdGhlIEdQSU8gb3IgcGluY3RybCBtb2RlIGNvbmZpZ3VyYXRpb24sIHRo ZQpmdW5jdGlvbiBqdW1wcyB0byBvdXRfZXJyIGFuZCBieXBhc3NlcyB0aGUgcmVzdG9yYXRpb24g b2YgdGhlIHN5c3JxIHN0YXRlLgpDb3VsZCB0aGlzIHBlcm1hbmVudGx5IGRpc2FibGUgc3lzcnEg ZmVhdHVyZXMgc3lzdGVtLXdpZGU/CgoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzIGEgcHJlLWV4 aXN0aW5nIGlzc3VlLCBidXQgaXMgdGhlcmUgYSB1c2UtYWZ0ZXItZnJlZSB2dWxuZXJhYmlsaXR5 CmR1cmluZyBkZXZpY2UgdGVhcmRvd24/CgpMb29raW5nIGF0IGNwY2FwX3BoeV9pcnFfdGhyZWFk KCk6Cgpkcml2ZXJzL3BoeS9tb3Rvcm9sYS9waHktY3BjYXAtdXNiLmM6Y3BjYXBfcGh5X2lycV90 aHJlYWQoKSB7CiAgICBpZiAoIWF0b21pY19yZWFkKCZkZGF0YS0+YWN0aXZlKSkKICAgICAgICBy ZXR1cm4gSVJRX05PTkU7CiAgICAKICAgIHNjaGVkdWxlX2RlbGF5ZWRfd29yaygmZGRhdGEtPmRl dGVjdF93b3JrLCBtc2Vjc190b19qaWZmaWVzKDEpKTsKfQoKQW5kIGluIGNwY2FwX3VzYl9waHlf cmVtb3ZlKCksIGNhbmNlbF9kZWxheWVkX3dvcmtfc3luYygpIGlzIGNhbGxlZCwgYnV0CmJlY2F1 c2UgZGV2bV9yZXF1ZXN0X3RocmVhZGVkX2lycSgpIGlzIHVzZWQsIHRoZSBJUlEgaXMgZnJlZWQg YWZ0ZXIKcmVtb3ZlKCkgZmluaXNoZXMuCgpJZiB0aGUgSVJRIHRocmVhZCBpcyBwcmVlbXB0ZWQg aW1tZWRpYXRlbHkgYWZ0ZXIgcmVhZGluZyBkZGF0YS0+YWN0aXZlLApjYW4gaXQgcmVzdW1lIGR1 cmluZyBmcmVlX2lycSgpLCBhbmQgcXVldWUgZGV0ZWN0X3dvcmsgb24gZnJlZWQgbWVtb3J5CmFm dGVyIGRldnJlcyBmcmVlcyBkZGF0YT8KCgpbU2V2ZXJpdHk6IEhpZ2hdClRoaXMgaXMgYSBwcmUt ZXhpc3RpbmcgaXNzdWUsIGJ1dCBkb2VzIHRoZSBoYXJkd2FyZSB0ZWFyZG93biBpbgpjcGNhcF91 c2JfcGh5X3JlbW92ZSgpIHJhY2Ugd2l0aCB0aGUgYmFja2dyb3VuZCB3b3JrZXI/CgpMb29raW5n IGF0IGNwY2FwX3VzYl9waHlfcmVtb3ZlKCk6Cgpkcml2ZXJzL3BoeS9tb3Rvcm9sYS9waHktY3Bj YXAtdXNiLmM6Y3BjYXBfdXNiX3BoeV9yZW1vdmUoKSB7CiAgICBjcGNhcF91c2Jfc2V0X2lkbGVf bW9kZShkZGF0YSk7CiAgICBjcGNhcF91c2JfdHJ5X211c2JfbWFpbGJveChkZGF0YSwgTVVTQl9W QlVTX09GRik7CiAgICAKICAgIHVzYl9yZW1vdmVfcGh5KCZkZGF0YS0+cGh5KTsKICAgIGNhbmNl bF9kZWxheWVkX3dvcmtfc3luYygmZGRhdGEtPmRldGVjdF93b3JrKTsKfQoKVGhlIGRyaXZlciBh dHRlbXB0cyB0byBmb3JjZSBhbiBpZGxlIHN0YXRlIGJlZm9yZSBzdG9wcGluZyB0aGUgYmFja2dy b3VuZAp3b3JrZXIgY3BjYXBfdXNiX2RldGVjdCgpLgoKU2luY2UgdGhlIHdvcmtlciB0aHJlYWQg ZG9lc24ndCBjaGVjayBkZGF0YS0+YWN0aXZlLCBjb3VsZCBpdCBjb25jdXJyZW50bHkKbW9kaWZ5 IHRoZSBzYW1lIHJlZ21hcCByZWdpc3RlcnMgYW5kIHBpbmN0cmwgc3RhdGVzLCBsZWF2aW5nIHRo ZSBoYXJkd2FyZQppbiBhbiB1bmRlZmluZWQgc3RhdGU/CgotLSAKU2FzaGlrbyBBSSByZXZpZXcg wrcgaHR0cHM6Ly9zYXNoaWtvLmRldi8jL3BhdGNoc2V0LzIwMjYwNzA0MDczODQzLjE3NTA0NTgt MS1pdm8uZy5kaW1pdHJvdi43NUBnbWFpbC5jb20/cGFydD0xCgotLSAKbGludXgtcGh5IG1haWxp bmcgbGlzdApsaW51eC1waHlAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwczovL2xpc3RzLmluZnJh ZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1waHkK 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 D53E9357D09 for ; Sat, 4 Jul 2026 07:49:12 +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=1783151362; cv=none; b=p5VnpM61RNQrR35jgNKypYiCDo0k1i8KV3Tj/hP7BM1GFwAPgqx/4M8+jFklz+aCU6n59U/l2KkgrJTS7OnmVxEQeXKdfDDqp80c/9M7IxZ5u8KKJMaJZtvjiXA7OT32jq9I/MMxUnD62rlt1mS5V7ZSLWyvozURdQIuhiXsl94= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783151362; c=relaxed/simple; bh=eeAJQtgaqEdc9Yh0apNy5SUm86DKu3J9K38HjtipU6c=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=kW0/AeVAfp0XKGPvdEy72H8UjnHeLJqwGCLXqiHmOCQJugKiS8CjMgpiq9sMTSvk6rByHH1FJj2ZSLVTjbXGunkbDK1u20uBmbOv+yWithqJOOe48y5wtDZnGF0EIoocRTm9l6bCxXW5kVTO+XSOVH7IRRxLenKLzeYgFggF6Rs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UiH2Ht1F; 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="UiH2Ht1F" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D0471F00A3A; Sat, 4 Jul 2026 07:49:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783151348; bh=3xjteroih40a3MfOMXhUMF5dbo99yBBa1fmVNc6A6go=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=UiH2Ht1FuWLciuKlQGUrZNotQ7JUh85tgwL5nYQFoK2d8nq28Kt2WWFQ9nLsnHglq nS5jM6vQ9iP6LyTz3T+uwAcbSoS16H0nl9BSlSv6+p7K/msMpeGUFvQV7S8m1puE87 4dHI08eHGNGTk0CIkGhJp6rzdJjl8AzDhmJyaI0xIgd8XKJyB46ddLsqTW0Um7359/ mPHcbojv7TcAh79WmZsnTUmjf4atWnm+GMTDgmBL0PCZBjPAAosav0re0TF0WPjqF2 CP9nEC+ybhAuB5kdfLAjLca0Ssmh9bqYiMVgPsghWxKohElvjGYn1pEKarN5Pd3MJN DOBizT0qvW5+A== From: sashiko-bot@kernel.org Subject: Re: [PATCH 1/5] phy: cpcap-usb: Prevent line glitches from triggering sysrq Reply-To: sashiko-reviews@lists.linux.dev To: "Ivaylo Dimitrov" Cc: vkoul@kernel.org, linux-phy@lists.infradead.org, devicetree@vger.kernel.org, conor+dt@kernel.org, neil.armstrong@linaro.org, olteanv@gmail.com, robh@kernel.org In-Reply-To: <20260704073843.1750458-2-ivo.g.dimitrov.75@gmail.com> References: <20260704073843.1750458-1-ivo.g.dimitrov.75@gmail.com> <20260704073843.1750458-2-ivo.g.dimitrov.75@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 04 Jul 2026 07:49:07 +0000 Message-Id: <20260704074908.3D0471F00A3A@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 5 potential issue(= s) to consider: New issues: - [High] The global SysRq support mask is permanently altered if an error o= ccurs during UART mode configuration. - [High] Flawed bitwise logic fails to effectively disable SysRq in system = configurations that use specific feature masks, leaving the system vulnerab= le to glitches. - [High] The driver modifies global system configuration to mask a local ha= rdware glitch, introducing system-wide side effects and race conditions. Pre-existing issues: - [High] A Use-After-Free vulnerability exists because devres-managed IRQs = can queue delayed work on freed memory after `remove()` completes. - [High] Hardware teardown in `remove()` races with the background worker, = leading to undefined hardware state. -- commit d89e10225f70bc2771f7d996decb42920d32fe88 Author: Tony Lindgren phy: cpcap-usb: Prevent line glitches from triggering sysrq This commit attempts to prevent random sysrq events when switching from USB to debug serial port mode. It temporarily disables sysrq during mode changes to mask line glitches. > diff --git a/drivers/phy/motorola/phy-cpcap-usb.c b/drivers/phy/motorola/= phy-cpcap-usb.c > --- a/drivers/phy/motorola/phy-cpcap-usb.c > +++ b/drivers/phy/motorola/phy-cpcap-usb.c [ ... ] > @@ -413,7 +414,12 @@ static int cpcap_usb_gpio_set_mode(struct cpcap_phy_= ddata *ddata, > =20 > static int cpcap_usb_set_uart_mode(struct cpcap_phy_ddata *ddata) > { > - int error; > + int sysrq, error; > + > + /* Disable sysrq to prevent random sysrq events on line glitches */ > + sysrq =3D sysrq_mask(); > + if (sysrq & 1) > + sysrq_toggle_support(sysrq & ~1); [Severity: High] Does modifying the global sysrq state here create a race condition? If an administrator concurrently modifies the sysrq settings via /proc/sys/kernel/sysrq, will the restoration call at the end of this function blindly overwrite their new state? [Severity: High] Will this correctly disable sysrq if the system is configured with a specific feature mask? If the administrator clears the SYSRQ_ENABLE_ALL bit (bit 0) but leaves other features enabled, sysrq & 1 evaluates to 0, bypassing the disablement. If bit 0 and other bits are set, sysrq & ~1 disables the 'enable all' flag but leaves the specific logging/dumping features actively enabled. [ ... ] > @@ -448,6 +454,9 @@ static int cpcap_usb_set_uart_mode(struct cpcap_phy_d= data *ddata) > if (error) > goto out_err; > =20 > + if (sysrq & 1) > + sysrq_toggle_support(sysrq); > + > return 0; > =20 > out_err: [Severity: High] Does this error path permanently alter the sysrq support mask? If a failure occurs during the GPIO or pinctrl mode configuration, the function jumps to out_err and bypasses the restoration of the sysrq state. Could this permanently disable sysrq features system-wide? [Severity: High] This is a pre-existing issue, but is there a use-after-free vulnerability during device teardown? Looking at cpcap_phy_irq_thread(): drivers/phy/motorola/phy-cpcap-usb.c:cpcap_phy_irq_thread() { if (!atomic_read(&ddata->active)) return IRQ_NONE; =20 schedule_delayed_work(&ddata->detect_work, msecs_to_jiffies(1)); } And in cpcap_usb_phy_remove(), cancel_delayed_work_sync() is called, but because devm_request_threaded_irq() is used, the IRQ is freed after remove() finishes. If the IRQ thread is preempted immediately after reading ddata->active, can it resume during free_irq(), and queue detect_work on freed memory after devres frees ddata? [Severity: High] This is a pre-existing issue, but does the hardware teardown in cpcap_usb_phy_remove() race with the background worker? Looking at cpcap_usb_phy_remove(): drivers/phy/motorola/phy-cpcap-usb.c:cpcap_usb_phy_remove() { cpcap_usb_set_idle_mode(ddata); cpcap_usb_try_musb_mailbox(ddata, MUSB_VBUS_OFF); =20 usb_remove_phy(&ddata->phy); cancel_delayed_work_sync(&ddata->detect_work); } The driver attempts to force an idle state before stopping the background worker cpcap_usb_detect(). Since the worker thread doesn't check ddata->active, could it concurrently modify the same regmap registers and pinctrl states, leaving the hardware in an undefined state? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260704073843.1750= 458-1-ivo.g.dimitrov.75@gmail.com?part=3D1