nuxfoundation.org header.b=C3zoHHBY; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE86CC4CEF7;
	Wed,  4 Feb 2026 14:43:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1770216205;
	bh=KQScA0WwwFdVH5i3prfIJaZY/Uay5WbGnkxYJqERFdI=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=C3zoHHBYXqlWxDb5ff6jB4IF338+R9igfwHOaRlDcY3d4UKA3wyi41nRY3Mmr7FOK
	 sumi+6nEXZ+TOxyYxCmQsBCDQO+p7QI8BHOto/BJfZqIoTDziynbB9vumT4hElZBFQ
	 ypAeuNGKnY6sz194WvkWb3smiy/6xJK9SJ0kei74=
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev,
	Benjamin Tissoires <bentiss@kernel.org>,
	Salvatore Bonaccorso <carnil@debian.org>
Subject: [PATCH 5.10 019/161] HID: usbhid: paper over wrong bNumDescriptor field
Date: Wed,  4 Feb 2026 15:38:02 +0100
Message-ID: <20260204143852.455385080@linuxfoundation.org>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <20260204143851.755002596@linuxfoundation.org>
References: <20260204143851.755002596@linuxfoundation.org>
User-Agent: quilt/0.69
X-stable: review
X-Patchwork-Hint: ignore
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-DKIM: signer='linuxfoundation.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: 0.4 (/)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://mxroutedocs.com/directadmin/spamfilters/
 ---
 Content analysis details:   (0.4 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: 4

5.10-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Benjamin Tissoires <bentiss@kernel.org>

commit f28beb69c51517aec7067dfb2074e7c751542384 upstream.

Some faulty devices (ZWO EFWmini) have a wrong optional HID class
descriptor count compared to the provided length.

Given that we plainly ignore those optional descriptor, we can attempt
to fix the provided number so we do not lock out those devices.

Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Cc: Salvatore Bonaccorso <carnil@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/hid/usbhid/hid-core.c |   17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -985,6 +985,7 @@ static int usbhid_parse(struct hid_devic
 	struct usb_device *dev = interface_to_usbdev (intf);
 	struct hid_descriptor *hdesc;
 	struct hid_class_descriptor *hcdesc;
+	__u8 fixed_opt_descriptors_size;
 	u32 quirks = 0;
 	unsigned int rsize = 0;
 	char *rdesc;
@@ -1015,7 +1016,21 @@ static int usbhid_parse(struct hid_devic
 			      (hdesc->bNumDescriptors - 1) * sizeof(*hcdesc)) {
 		dbg_hid("hid descriptor invalid, bLen=%hhu bNum=%hhu\n",
 			hdesc->bLength, hdesc->bNumDescriptors);
-		return -EINVAL;
+
+		/*
+		 * Some devices may expose a wrong number of descriptors compared
+		 * to the provided length.
+		 * However, we ignore the optional hid class descriptors entirely
+		 * so we can safely recompute the proper field.
+		 */
+		if (hdesc->bLength >= sizeof(*hdesc)) {
+			fixed_opt_descriptors_size = hdesc->bLength - sizeof(*hdesc);
+
+			hid_warn(intf, "fixing wrong optional hid class descriptors count\n");
+			hdesc->bNumDescriptors = fixed_opt_descriptors_size / sizeof(*hcdesc) + 1;
+		} else {
+			return -EINVAL;
+		}
 	}
 
 	hid->version = le16_to_cpu(hdesc->bcdHID);




From - Wed Feb 04 14:43:43 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-213399-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id oGiTJxRbg2m/wBMAYBR5ng
	(envelope-from <stable+bounces-213399-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Wed, 04 Feb 2026 14:43:32 +0000
Return-path: <stable+bounces-213399-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Wed, 04 Feb 2026 14:43:32 +0000
Received: from sto.lore.kernel.org ([172.232.135.74])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-213399-hi=josie.lol@vger.kernel.org>)
	id 1vne6O-000000062qK-1DrH
	for hi@josie.lol;
	Wed, 04 Feb 2026 14:43:32 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sto.lore.kernel.org (Postfix) with ESMTP id C69DC3006682
	for <hi@josie.lol>; Wed,  4 Feb 2026 14:43:30 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 825E440758D;
	Wed,  4 Feb 2026 14:43:28 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="wF76QtGo"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 600BB280A3B;
	Wed,  4 Feb 2026 14:43:28 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1770216208; cv=none; b=UmzsXFPlFbYPUGPkFvgGD/DoczbAriAsj/zRXE1o292+dq6v31bgMSYuJ5e+uO8BlErOZvc/MquHY06ik0h7N3ovD6/3SwWHB2pUjMQ8mBQOp5we6QySPtUw74RowPxZ35LkriZfHp7CHKJe/+gKWxzmUrzSi1NyjUmrrVbZ8WE=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1770216208; c=relaxed/simple;
	bh=VvtFOLHLJiRka/Xbo7FwGM2NZiLUilW1M40IUJ3+6UA=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=D7cRqup5iyPDc0mJYJGDsfe5EYWMNjzHZvqMsgYc5GcOa78yalMwLLG0aYMBDtf7YLTsGLhqGgUlNendNtNhhBqC0+iRJa0tPhZgAmhplQ97O7AjlePn0bq5i2cxk6hI913Rz3+CnmEuyXnwgqIvtviK+Trx0ITsG/t4A3dGEqc=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=wF76QtGo; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2EADC4CEF7;
	Wed,  4 Feb 2026 14:43:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1770216208;
	bh=VvtFOLHLJiRka/Xbo7FwGM2NZiLUilW1M40IUJ3+6UA=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=wF76QtGo1D6rgi8U+7dAJcXlrcOHVvkv2pJZUBQQg51C7pbaAUQYj/EQ+Bi3yDfev
	 76UXztVY0bWLEYQpP8fYy/u0k+l3BQHDZR+MLInUDlsu+ptiAPG5jSF4wKVmrC53DO
	 l/0QX41Xns/HX7dOQZwh61Ek8fUOmElf+hKDHuc8=
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev,
	Maurizio Lombardi <mlombard@redhat.com>,
	Sagi Grimberg <sagi@grimberg.me>,
	Keith Busch <kbusch@kernel.org>,
	Sasha Levin <sashal@kernel.org>
Subject: [PATCH 5.10 002/161] nvmet-tcp: remove boilerplate code
Date: Wed,  4 Feb 2026 15:37:45 +0100
Message-ID: <20260204143851.848546164@linuxfoundation.org>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <20260204143851.755002596@linuxfoundation.org>
References: <20260204143851.755002596@linuxfoundation.org>
User-Agent: quilt/0.69
X-stable: review
X-Patchwork-Hint: ignore
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-DKIM: signer='linuxfoundation.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: 0.4 (/)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://mxroutedocs.com/directadmin/spamfilters/
 ---
 Content analysis details:   (0.4 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                             blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: linuxfoundation.org]
  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [172.232.135.74 listed in list.dnswl.org]
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: 4

5.10-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Maurizio Lombardi <mlombard@redhat.com>

[ Upstream commit 75011bd0f9c55db523242f9f9a0b0b826165f14b ]

Simplify the nvmet_tcp_handle_h2c_data_pdu() function by removing
boilerplate code.

Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Stable-dep-of: 32b63acd78f5 ("nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/nvme/target/tcp.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c
index 6019eee1f9bdf..d7b368102ad9a 100644
--- a/drivers/nvme/target/tcp.c
+++ b/drivers/nvme/target/tcp.c
@@ -933,8 +933,7 @@ static int nvmet_tcp_handle_h2c_data_pdu(struct nvmet_tcp_queue *queue)
 		if (unlikely(data->ttag >= queue->nr_cmds)) {
 			pr_err("queue %d: received out of bound ttag %u, nr_cmds %u\n",
 				queue->idx, data->ttag, queue->nr_cmds);
-			nvmet_tcp_fatal_error(queue);
-			return -EPROTO;
+			goto err_proto;
 		}
 		cmd = &queue->cmds[data->ttag];
 	} else {
@@ -945,9 +944,7 @@ static int nvmet_tcp_handle_h2c_data_pdu(struct nvmet_tcp_queue *queue)
 		pr_err("ttag %u unexpected data offset %u (expected %u)\n",
 			data->ttag, le32_to_cpu(data->data_offset),
 			cmd->rbytes_done);
-		/* FIXME: use path and transport errors */
-		nvmet_tcp_fatal_error(queue);
-		return -EPROTO;
+		goto err_proto;
 	}
 
 	exp_data_len = le32_to_cpu(data->hdr.plen) -
@@ -960,9 +957,7 @@ static int nvmet_tcp_handle_h2c_data_pdu(struct nvmet_tcp_queue *queue)
 		     cmd->pdu_len == 0 ||
 		     cmd->pdu_len > NVMET_TCP_MAXH2CDATA)) {
 		pr_err("H2CData PDU len %u is invalid\n", cmd->pdu_len);
-		/* FIXME: use proper transport errors */
-		nvmet_tcp_fatal_error(queue);
-		return -EPROTO;
+		goto err_proto;
 	}
 	cmd->pdu_recv = 0;
 	nvmet_tcp_map_pdu_iovec(cmd);
@@ -970,6 +965,11 @@ static int nvmet_tcp_handle_h2c_data_pdu(struct nvmet_tcp_queue *queue)
 	queue->rcv_state = NVMET_TCP_RECV_DATA;
 
 	return 0;
+
+err_proto:
+	/* FIXME: use proper transport errors */
+	nvmet_tcp_fatal_error(queue);
+	return -EPROTO;
 }
 
 static int nvmet_tcp_done_recv_pdu(struct nvmet_tcp_queue *queue)
-- 
2.51.0





From - Wed Feb 04 14:43:43 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-213390-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id eJrtJxRbg2kijhMAYBR5ng
	(envelope-from <stable+bounces-213390-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Wed, 04 Feb 2026 14:43:32 +0000
Return-path: <stable+bounces-213390-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Wed, 04 Feb 2026 14:43:32 +0000
Received: from sea.lore.kernel.org ([172.234.253.10])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-213390-hi=josie.lol@vger.kernel.org>)
	id 1vne6O-000000062qh-1ddX
	for hi@josie.lol;
	Wed, 04 Feb 2026 14:43:32 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sea.lore.kernel.org (Postfix) with ESMTP id 53D4430097D0
	for <hi@josie.lol>; Wed,  4 Feb 2026 14:43:01 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id A164040758D;
	Wed,  4 Feb 2026 14:42:59 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="oUKj0sBn"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 7ED501EA84;
	Wed,  4 Feb 2026 14:42:59 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1770216179; cv=none; b=na8xNp3zd9BTRptSV/NwLDCXvHQzfprfvp+Mh8N4IrV8d/0qVjd2LbwMhgWvAIpKZ8vbf2STz/ueIdO4jvVekWy4xkQlvGR4nGtw29YUC5CqVy/97l+PIOV0g8nJ11SlXxLPeqJ30GlPDQPghvQpGdnSTX0uzsfgQs6oDmlDisU=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1770216179; c=relaxed/simple;
	bh=rhDF6y1K2DXFq7nyyTCSM8GXTMo6w8k9Lfsw8jE5MZs=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=sTwMOlWVqjVpLpXr/GYKPLGU8k0bmF3R9riIan8Y7txCVATag38PNUdo7mtgrcjFT/vRV8zEvy4+y8x/f8eZYYTEtiRxV6YAwK7qgaB0P46rMvuYXNq9uUKrUUijQpzOvdqXTCLmvtocJjJirV31d5zRBivmWTHFGKuVjEGydfA=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=oUKj0sBn; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 90E83C116C6;
	Wed,  4 Feb 2026 14:42:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1770216179;
	bh=rhDF6y1K2DXFq7nyyTCSM8GXTMo6w8k9Lfsw8jE5MZs=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=oUKj0sBnMEiP6CVvVoB9tfrpYBH+dTtfjfQSPj+MJFM4mNPAZ/Kikx8rPwWYgWZAY
	 2XVFJ2Gog9X/pqQ0vQkzAmLZujrRDWdgxFaBbNApzOxuIBhehxsKo0T6R24kGQ5OIh
	 Qwn3IG0qbYBEZEW6p+gy9aV5o/O0WUKkeELWJjEA=
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev,
	syzbot+07f3f38f723c335f106d@syzkaller.appspotmail.com,
	Eric Dumazet <edumazet@google.com>,
	Jamal Hadi Salim <jhs@mojatatu.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Sasha Levin <sashal@kernel.org>
Subject: [PATCH 5.10 011/161] net/sched: sch_qfq: do not free existing class in qfq_change_class()
Date: Wed,  4 Feb 2026 15:37:54 +0100
Message-ID: <20260204143852.169872461@linuxfoundation.org>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <20260204143851.755002596@linuxfoundation.org>
References: <20260204143851.755002596@linuxfoundation.org>
User-Agent: quilt/0.69
X-stable: review
X-Patchwork-Hint: ignore
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-DKIM: signer='linuxfoundation.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: 0.4 (/)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://mxroutedocs.com/directadmin/spamfilters/
 ---
 Content analysis details:   (0.4 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [172.234.253.10 listed in list.dnswl.org]
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: 4

5.10-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <edumazet@google.com>

[ Upstream commit 3879cffd9d07aa0377c4b8835c4f64b4fb24ac78 ]

Fixes qfq_change_class() error case.

cl->qdisc and cl should only be freed if a new class and qdisc
were allocated, or we risk various UAF.

Fixes: 462dbc9101ac ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost")
Reported-by: syzbot+07f3f38f723c335f106d@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6965351d.050a0220.eaf7.00c5.GAE@google.com/T/#u
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/20260112175656.17605-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 net/sched/sch_qfq.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index 34a6c4ec9a157..9751de2d95e78 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -532,8 +532,10 @@ static int qfq_change_class(struct Qdisc *sch, u32 classid, u32 parentid,
 	return 0;
 
 destroy_class:
-	qdisc_put(cl->qdisc);
-	kfree(cl);
+	if (!existing) {
+		qdisc_put(cl->qdisc);
+		kfree(cl);
+	}
 	return err;
 }
 
-- 
2.51.0





From - Wed Feb 04 14:43:43 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-213392-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id sIePGhtbg2kijhMAYBR5ng
	(envelope-from <stable+bounces-213392-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Wed, 04 Feb 2026 14:43:39 +0000
Return-path: <stable+bounces-213392-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Wed, 04 Feb 2026 14:43:39 +0000
Received: from sea.lore.kernel.org ([172.234.253.10])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-213392-hi=josie.lol@vger.kernel.org>)
	id 1vne6V-0000000630x-0bHr
	for hi@josie.lol;
	Wed, 04 Feb 2026 14:43:39 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sea.lore.kernel.org (Postfix) with ESMTP id 70F3B300DF6C
	for <hi@josie.lol>; Wed,  4 Feb 2026 14:43:06 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id D5170345CA5;
	Wed,  4 Feb 2026 14:43:05 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="cLy0wuW2"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 B3143280A3B;
	Wed,  4 Feb 2026 14:43:05 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1770216185; cv=none; b=J4r410DgalYnYvrJf9Wsgm19ewKPuP0IEHhb6x8YWtclpiHfHuhYhJfxSenq+D/vQPuBhiFCVeZxFfc3SOzSbbXER9xsYwkigDOcJ5R1ASgwwy1PZEWrc6L+G9ZdhHEVwvT20mur92UmlX+igCm+G8lYD7j37jE4zEMNwGT8XYM=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1770216185; c=relaxed/simple;
	bh=izc3osVD0R35hxaTUjCovLcHFR1YrpcWcLEH5uuwbqs=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=QMDqOWw9aC2Uy0hAszvYW88pOwPW/O4pce9QD2vpU/TTsINcD4lR6Uz96mOoQfAJKD1fFA9L9a3ovd0Tnx4dfTmB064UUxWxZj9pKCidxV1YJQ/yH8M8E5GI4BEHLCzt07SnOZpjyzEbXgI2ANsd/B1XK/0qhn3VnElrc0a3btU=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=cLy0wuW2; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A97DC4CEF7;
	Wed,  4 Feb 2026 14:43:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1770216185;
	bh=izc3osVD0R35hxaTUjCovLcHFR1YrpcWcLEH5uuwbqs=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=cLy0wuW2Wq266l/0fBlEE+U6in53TLaoeXcJIr9oiys5DCqsFYo/cyoyoh+M3s3eh
	 RAO1w+krIyZuhTWfMqsNxo11xdfJrBvSXJvD4LygXYasudH9fTFLA5tE/yiNH+4YHI
	 3DUFpclrDRIH+YRRsH4yi/hHLV0AbyfAtx1INItI=
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev,
	Bagas Sanjaya <bagasdotme@gmail.com>,
	Thomas Graf <tgraf@suug.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sasha Levin <sashal@kernel.org>
Subject: [PATCH 5.10 013/161] textsearch: describe @list member in ts_ops search
Date: Wed,  4 Feb 2026 15:37:56 +0100
Message-ID: <20260204143852.242377476@linuxfoundation.org>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <20260204143851.755002596@linuxfoundation.org>
References: <20260204143851.755002596@linuxfoundation.org>
User-Agent: quilt/0.69
X-stable: review
X-Patchwork-Hint: ignore
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-DKIM: signer='linuxfoundation.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: 0.4 (/)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://mxroutedocs.com/directadmin/spamfilters/
 ---
 Content analysis details:   (0.4 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                             blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: linuxfoundation.org]
  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [172.234.253.10 listed in list.dnswl.org]
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: 4

5.10-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Bagas Sanjaya <bagasdotme@gmail.com>

[ Upstream commit f26528478bb102c28e7ac0cbfc8ec8185afdafc7 ]

Sphinx reports kernel-doc warning:

WARNING: ./include/linux/textsearch.h:49 struct member 'list' not described in 'ts_ops'

Describe @list member to fix it.

Link: https://lkml.kernel.org/r/20251219014006.16328-4-bagasdotme@gmail.com
Fixes: 2de4ff7bd658 ("[LIB]: Textsearch infrastructure.")
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 include/linux/textsearch.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/textsearch.h b/include/linux/textsearch.h
index 13770cfe33ad8..1389959b68422 100644
--- a/include/linux/textsearch.h
+++ b/include/linux/textsearch.h
@@ -35,6 +35,7 @@ struct ts_state
  * @get_pattern: return head of pattern
  * @get_pattern_len: return length of pattern
  * @owner: module reference to algorithm
+ * @list: list to search
  */
 struct ts_ops
 {
-- 
2.51.0





From - Wed Feb 04 14:43:47 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-213402-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id CPZaJB1bg2kijhMAYBR5ng
	(envelope-from <stable+bounces-213402-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Wed, 04 Feb 2026 14:43:41 +0000
Return-path: <stable+bounces-213402-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Wed, 04 Feb 2026 14:43:41 +0000
Received: from sto.lore.kernel.org ([172.232.135.74])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-213402-hi=josie.lol@vger.kernel.org>)
	id 1vne6X-0000000635i-0ZFE
	for hi@josie.lol;
	Wed, 04 Feb 2026 14:43:41 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sto.lore.kernel.org (Postfix) with ESMTP id DA25E3004F12
	for <hi@josie.lol>; Wed,  4 Feb 2026 14:43:39 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 1C27F345CA5;
	Wed,  4 Feb 2026 14:43:38 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="KgBKwNIb"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 ED51A280A3B;
	Wed,  4 Feb 2026 14:43:37 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1770216218; cv=none; b=FKI1dd65slnbdOYdtM8lYn+S70YDO1CHNATI/pHM1Rkbpw2/uZ2DbYwPWts6guAEVG04wmwjC2r/T6k7mueXQjEp0mwcpKPuSUEMW6HyO2UYoHezhcYjYcfUnVKgRHskM39DcbQClqmeRdoog/me18F+AkX6IoO/iPSowdRq4d4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1770216218; c=relaxed/simple;
	bh=ryUG+DAngtHih/4Xm6jvNj4NRYvcOjnG5PlIAHqNBg4=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=LBMVBEDlTH1XquqHUCchhwrc1QY5w5psVFQ+P6BnttURTK6eO5ypIZuV+oobjmcYg86E8js4DfeXS9qE+Wz3+2DhTIWk0nEX1yDWc4CauHJ7WBcQccaAg3JrhdeowL5Yazhp28gPoQieaSI8+sthfrfvxs+BHQwx4tPVNAt7qug=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=KgBKwNIb; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F716C4CEF7;
	Wed,  4 Feb 2026 14:43:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1770216217;
	bh=ryUG+DAngtHih/4Xm6jvNj4NRYvcOjnG5PlIAHqNBg4=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=KgBKwNIbpHrYHkjwTlk3oDKNpBgWfJwdZ5g6H9/fzehiUELOsp0mRew950MKmwIbx
	 VRI4AYlreFo22Pvfw4kbDI0JY9s57fRuESpq6K93+YVoaG4IrzMZ8DDYsMEp5HHSEG
	 AeOYAztT/ZpP9yjOTI9HxzE9ut3kyfv7FFTXvero=
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev,
	Luca Ceresoli <luca.ceresoli@bootlin.com>,
	=?UTF-8?q?Th=C3=A9o=20Lebrun?= <theo.lebrun@bootlin.com>,
	Vinod Koul <vkoul@kernel.org>
Subject: [PATCH 5.10 022/161] phy: rockchip: inno-usb2: fix communication disruption in gadget mode
Date: Wed,  4 Feb 2026 15:38:05 +0100
Message-ID: <20260204143852.563376077@linuxfoundation.org>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <20260204143851.755002596@linuxfoundation.org>
References: <20260204143851.755002596@linuxfoundation.org>
User-Agent: quilt/0.69
X-stable: review
X-Patchwork-Hint: ignore
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-DKIM: signer='linuxfoundation.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: 0.4 (/)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://mxroutedocs.com/directadmin/spamfilters/
 ---
 Content analysis details:   (0.4 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                             blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: linuxfoundation.org]
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: 4

5.10-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Luca Ceresoli <luca.ceresoli@bootlin.com>

commit 7d8f725b79e35fa47e42c88716aad8711e1168d8 upstream.

When the OTG USB port is used to power to SoC, configured as peripheral and
used in gadget mode, communication stops without notice about 6 seconds
after the gadget is configured and enumerated.

The problem was observed on a Radxa Rock Pi S board, which can only be
powered by the only USB-C connector. That connector is the only one usable
in gadget mode. This implies the USB cable is connected from before boot
and never disconnects while the kernel runs.

The related code flow in the PHY driver code can be summarized as:

 * the first time chg_detect_work starts (6 seconds after gadget is
   configured and enumerated)
   -> rockchip_chg_detect_work():
       if chg_state is UNDEFINED:
          property_enable(base, &rphy->phy_cfg->chg_det.opmode, false); [Y]

 * rockchip_chg_detect_work() changes state and re-triggers itself a few
   times until it reaches the DETECTED state:
   -> rockchip_chg_detect_work():
       if chg_state is DETECTED:
          property_enable(base, &rphy->phy_cfg->chg_det.opmode, true); [Z]

At [Y] all existing communications stop. E.g. using a CDC serial gadget,
the /dev/tty* devices are still present on both host and device, but no
data is transferred anymore. The later call with a 'true' argument at [Z]
does not restore it.

Due to the lack of documentation, what chg_det.opmode does exactly is not
clear, however by code inspection it seems reasonable that is disables
something needed to keep the communication working, and testing proves that
disabling these lines lets gadget mode keep working. So prevent changes to
chg_det.opmode when there is a cable connected (VBUS present).

Fixes: 98898f3bc83c ("phy: rockchip-inno-usb2: support otg-port for rk3399")
Cc: stable@vger.kernel.org
Closes: https://lore.kernel.org/lkml/20250414185458.7767aabc@booty/
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://patch.msgid.link/20251127-rk3308-fix-usb-gadget-phy-disconnect-v2-2-dac8a02cd2ca@bootlin.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/phy/rockchip/phy-rockchip-inno-usb2.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -699,7 +699,8 @@ static void rockchip_chg_detect_work(str
 		if (!rport->suspended)
 			rockchip_usb2phy_power_off(rport->phy);
 		/* put the controller in non-driving mode */
-		property_enable(base, &rphy->phy_cfg->chg_det.opmode, false);
+		if (!vbus_attach)
+			property_enable(base, &rphy->phy_cfg->chg_det.opmode, false);
 		/* Start DCD processing stage 1 */
 		rockchip_chg_enable_dcd(rphy, true);
 		rphy->chg_state = USB_CHG_STATE_WAIT_FOR_DCD;
@@ -763,7 +764,8 @@ static void rockchip_chg_detect_work(str
 		fallthrough;
 	case USB_CHG_STATE_DETECTED:
 		/* put the controller in normal mode */
-		property_enable(base, &rphy->phy_cfg->chg_det.opmode, true);
+		if (!vbus_attach)
+			property_enable(base, &rphy->phy_cfg->chg_det.opmode, true);
 		rockchip_usb2phy_otg_sm_work(&rport->otg_sm_work.work);
 		dev_dbg(&rport->phy->dev, "charger = %s\n",
 			 chg_to_string(rphy->chg_type));




From - Wed Feb 04 14:43:47 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-213401-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id 0GpDOx1bg2nJ9RMAYBR5ng
	(envelope-from <stable+bounces-213401-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Wed, 04 Feb 2026 14:43:41 +0000
Return-path: <stable+bounces-213401-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Wed, 04 Feb 2026 14:43:42 +0000
Received: from sin.lore.kernel.org ([104.64.211.4])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-213401-hi=josie.lol@vger.kernel.org>)
	id 1vne6W-0000000630e-4Bjq
	for hi@josie.lol;
	Wed, 04 Feb 2026 14:43:41 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sin.lore.kernel.org (Postfix) with ESMTP id DC7093004054
	for <hi@josie.lol>; Wed,  4 Feb 2026 14:43:36 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id F0C69345CA5;
	Wed,  4 Feb 2026 14:43:34 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="Bax34qkY"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 CE6B7280A3B;
	Wed,  4 Feb 2026 14:43:34 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1770216214; cv=none; b=KCUqi7J9E0Lx/LWI0Gt4sGgl30rA16+roSrdIQrNSxDvow3Ua9UkMFOMu4sKXnPSPIowLrs4Zt5uXUktlCOkLbeyUP/pNXkdvvXWKbI7CZ82jsInmuq2LUMvEzk+f6MNRAHE7gRivPo8a9uhpndMwHf5qzVZLTxeMUs+tjhOK54=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1770216214; c=relaxed/simple;
	bh=O1H2aEhRpmk2b+Iwa3mE2BXPEom8t/i6gtL3oIfRA+c=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=jsCYfIy+C+z1PtHSNgzhZzgCRjsTMT8qVtXEO9rh+HRiNn93UIpkXC1G8ZQwI97E89xgfc8E6p1V5xyI8ZJrfj/2mzR8BpupsCoWE9HQLCjHZ+CvW7HjjxxRguQwKsWUopbtN3tAs9Or0sgmSoWInt2UFb7qki46TeXewMmhiTQ=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=Bax34qkY; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4113C4CEF7;
	Wed,  4 Feb 2026 14:43:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1770216214;
	bh=O1H2aEhRpmk2b+Iwa3mE2BXPEom8t/i6gtL3oIfRA+c=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=Bax34qkYZHl0fUoAS9jiqiOzeM+MMQ53CbYdX0qw2wnKlv8CraPL473M9aeaXf6t/
	 SHdTVfnbuKhygyuL9dDC1CNN5kCAQRCDKNN/QvS3V3yGfEou+lI2bnvvJV60s5tMWQ
	 aV0n878q694S57Zt71cbCf07psM9xjG/A+D0V7Uc=
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev,
	syzbot <syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com>,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	Oleksij Rempel <o.rempel@pengutronix.de>,
	Marc Kleine-Budde <mkl@pengutronix.de>
Subject: [PATCH 5.10 021/161] net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts
Date: Wed,  4 Feb 2026 15:38:04 +0100
Message-ID: <20260204143852.527608936@linuxfoundation.org>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <20260204143851.755002596@linuxfoundation.org>
References: <20260204143851.755002596@linuxfoundation.org>
User-Agent: quilt/0.69
X-stable: review
X-Patchwork-Hint: ignore
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-DKIM: signer='linuxfoundation.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: 0.4 (/)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://mxroutedocs.com/directadmin/spamfilters/
 ---
 Content analysis details:   (0.4 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                             blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: linuxfoundation.org]
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: 4

5.10-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

commit 1809c82aa073a11b7d335ae932d81ce51a588a4a upstream.

Since j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is
called only when the timer is enabled, we need to call
j1939_session_deactivate_activate_next() if we cancelled the timer.
Otherwise, refcount for j1939_session leaks, which will later appear as

| unregister_netdevice: waiting for vcan0 to become free. Usage count = 2.

problem.

Reported-by: syzbot <syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com>
Closes: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Tested-by: Oleksij Rempel <o.rempel@pengutronix.de>
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
Link: https://patch.msgid.link/b1212653-8fa1-44e1-be9d-12f950fb3a07@I-love.SAKURA.ne.jp
Cc: stable@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/can/j1939/transport.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/net/can/j1939/transport.c
+++ b/net/can/j1939/transport.c
@@ -1680,8 +1680,16 @@ static int j1939_xtp_rx_rts_session_acti
 
 		j1939_session_timers_cancel(session);
 		j1939_session_cancel(session, J1939_XTP_ABORT_BUSY);
-		if (session->transmission)
+		if (session->transmission) {
 			j1939_session_deactivate_activate_next(session);
+		} else if (session->state == J1939_SESSION_WAITING_ABORT) {
+			/* Force deactivation for the receiver.
+			 * If we rely on the timer starting in j1939_session_cancel,
+			 * a second RTS call here will cancel that timer and fail
+			 * to restart it because the state is already WAITING_ABORT.
+			 */
+			j1939_session_deactivate_activate_next(session);
+		}
 
 		return -EBUSY;
 	}




From - Wed Feb 04 14:43:47 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-213393-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id aMkmKh9bg2lKhhQAYBR5ng
	(envelope-from <stable+bounces-213393-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Wed, 04 Feb 2026 14:43:43 +0000
Return-path: <stable+bounces-213393-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Wed, 04 Feb 2026 14:43:43 +0000
Received: from sea.lore.kernel.org ([172.234.253.10])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-213393-hi=josie.lol@vger.kernel.org>)
	id 1vne6Z-0000000637H-1HbD
	for hi@josie.lol;
	Wed, 04 Feb 2026 14:43:43 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sea.lore.kernel.org (Postfix) with ESMTP id 4B039300F5E6
	for <hi@josie.lol>; Wed,  4 Feb 2026 14:43:10 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 9757140758D;
	Wed,  4 Feb 2026 14:43:09 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="g9J0Ur/C"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 73EF61EA84;
	Wed,  4 Feb 2026 14:43:09 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1770216189; cv=none; b=U8IdSC98SCwOyVHkBqYrnkEuK0+AfhRisgsobxbPUNJ3twrpeqEWuB9DnO1P5XCdaROGwa5UVAD1maIidUDO9qzVEN4ZmaLlh2BRrLPCxCp1jfV42NpBLte7gv+00xyAnf+RrYMW+ZhoZKtS+yFTPbaocdvVRqyNLrqDUftBAHw=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1770216189; c=relaxed/simple;
	bh=UpX8iYCwAEcJi/Gw4V1IZ1WN1gbDXzRFgwVLzjZzw7I=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=BfPIn4Ow0ARVs6kMoPP5YfrueAR/QJfE+gD0wrpHRqPO/E++Pn3v9tp4ga12qiTQezxvs7DqWKs3co/airjzcPjuKjUy3bB99icQL46yVcr7OFc2Cm9rZ8qePKVwAnPK4KhFt4dHGgPBoxNwjY8kC8lTt0Cq0UDR5FGxgG9iMHE=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=g9J0Ur/C; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97959C4CEF7;
	Wed,  4 Feb 2026 14:43:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1770216189;
	bh=UpX8iYCwAEcJi/Gw4V1IZ1WN1gbDXzRFgwVLzjZzw7I=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=g9J0Ur/C7crFYBh3AeW1pT6LouShRVHmZNvo2BUfJu+VOqC9PxfntlZUDu/cZ7uUs
	 oT8tvE/7CLvvuoi+Io/hixV1qezuOE+ZUr8+i/HsmmhvJpWokA3wkYKQvfpGqtsX4u
	 zdwlJCudeIAkrek35DhiFaSCggIRRyPp4Cg6NRbo=
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev,
	Sheetal <sheetal@nvidia.com>,
	Thierry Reding <treding@nvidia.com>,
	Vinod Koul <vkoul@kernel.org>,
	Sasha Levin <sashal@kernel.org>
Subject: [PATCH 5.10 014/161] dmaengine: tegra-adma: Fix use-after-free
Date: Wed,  4 Feb 2026 15:37:57 +0100
Message-ID: <20260204143852.278622273@linuxfoundation.org>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <20260204143851.755002596@linuxfoundation.org>
References: <20260204143851.755002596@linuxfoundation.org>
User-Agent: quilt/0.69
X-stable: review
X-Patchwork-Hint: ignore
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-DKIM: signer='linuxfoundation.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: 0.4 (/)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://mxroutedocs.com/directadmin/spamfilters/
 ---
 Content analysis details:   (0.4 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: 4

5.10-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Sheetal <sheetal@nvidia.com>

[ Upstream commit 2efd07a7c36949e6fa36a69183df24d368bf9e96 ]

A use-after-free bug exists in the Tegra ADMA driver when audio streams
are terminated, particularly during XRUN conditions. The issue occurs
when the DMA buffer is freed by tegra_adma_terminate_all() before the
vchan completion tasklet finishes accessing it.

The race condition follows this sequence:

  1. DMA transfer completes, triggering an interrupt that schedules the
     completion tasklet (tasklet has not executed yet)
  2. Audio playback stops, calling tegra_adma_terminate_all() which
     frees the DMA buffer memory via kfree()
  3. The scheduled tasklet finally executes, calling vchan_complete()
     which attempts to access the already-freed memory

Since tasklets can execute at any time after being scheduled, there is
no guarantee that the buffer will remain valid when vchan_complete()
runs.

Fix this by properly synchronizing the virtual channel completion:
 - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the
   descriptors as terminated instead of freeing the descriptor.
 - Add the callback tegra_adma_synchronize() that calls
   vchan_synchronize() which kills any pending tasklets and frees any
   terminated descriptors.

Crash logs:
[  337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0
[  337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0

[  337.427562] Call trace:
[  337.427564]  dump_backtrace+0x0/0x320
[  337.427571]  show_stack+0x20/0x30
[  337.427575]  dump_stack_lvl+0x68/0x84
[  337.427584]  print_address_description.constprop.0+0x74/0x2b8
[  337.427590]  kasan_report+0x1f4/0x210
[  337.427598]  __asan_load8+0xa0/0xd0
[  337.427603]  vchan_complete+0x124/0x3b0
[  337.427609]  tasklet_action_common.constprop.0+0x190/0x1d0
[  337.427617]  tasklet_action+0x30/0x40
[  337.427623]  __do_softirq+0x1a0/0x5c4
[  337.427628]  irq_exit+0x110/0x140
[  337.427633]  handle_domain_irq+0xa4/0xe0
[  337.427640]  gic_handle_irq+0x64/0x160
[  337.427644]  call_on_irq_stack+0x20/0x4c
[  337.427649]  do_interrupt_handler+0x7c/0x90
[  337.427654]  el1_interrupt+0x30/0x80
[  337.427659]  el1h_64_irq_handler+0x18/0x30
[  337.427663]  el1h_64_irq+0x7c/0x80
[  337.427667]  cpuidle_enter_state+0xe4/0x540
[  337.427674]  cpuidle_enter+0x54/0x80
[  337.427679]  do_idle+0x2e0/0x380
[  337.427685]  cpu_startup_entry+0x2c/0x70
[  337.427690]  rest_init+0x114/0x130
[  337.427695]  arch_call_rest_init+0x18/0x24
[  337.427702]  start_kernel+0x380/0x3b4
[  337.427706]  __primary_switched+0xc0/0xc8

Fixes: f46b195799b5 ("dmaengine: tegra-adma: Add support for Tegra210 ADMA")
Signed-off-by: Sheetal <sheetal@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20251110142445.3842036-1-sheetal@nvidia.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/dma/tegra210-adma.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index d84010c2e4bf1..bcd1deb082615 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -344,10 +344,17 @@ static void tegra_adma_stop(struct tegra_adma_chan *tdc)
 		return;
 	}
 
-	kfree(tdc->desc);
+	vchan_terminate_vdesc(&tdc->desc->vd);
 	tdc->desc = NULL;
 }
 
+static void tegra_adma_synchronize(struct dma_chan *dc)
+{
+	struct tegra_adma_chan *tdc = to_tegra_adma_chan(dc);
+
+	vchan_synchronize(&tdc->vc);
+}
+
 static void tegra_adma_start(struct tegra_adma_chan *tdc)
 {
 	struct virt_dma_desc *vd = vchan_next_desc(&tdc->vc);
@@ -893,6 +900,7 @@ static int tegra_adma_probe(struct platform_device *pdev)
 	tdma->dma_dev.device_config = tegra_adma_slave_config;
 	tdma->dma_dev.device_tx_status = tegra_adma_tx_status;
 	tdma->dma_dev.device_terminate_all = tegra_adma_terminate_all;
+	tdma->dma_dev.device_synchronize = tegra_adma_synchronize;
 	tdma->dma_dev.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
 	tdma->dma_dev.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
 	tdma->dma_dev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
-- 
2.51.0





From - Wed Feb 04 14:43:52 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-213394-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id 8D8zBiRbg2lKhhQAYBR5ng
	(envelope-from <stable+bounces-213394-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Wed, 04 Feb 2026 14:43:48 +0000
Return-path: <stable+bounces-213394-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Wed, 04 Feb 2026 14:43:48 +0000
Received: from sea.lore.kernel.org ([172.234.253.10])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-213394-hi=josie.lol@vger.kernel.org>)
	id 1vne6d-000000063Gd-3NAB
	for hi@josie.lol;
	Wed, 04 Feb 2026 14:43:48 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sea.lore.kernel.org (Postfix) with ESMTP id 29FFF301052E
	for <hi@josie.lol>; Wed,  4 Feb 2026 14:43:14 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id CEB6D280A3B;
	Wed,  4 Feb 2026 14:43:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="mZWnzYJn"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 AC6591EA84;
	Wed,  4 Feb 2026 14:43:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1770216192; cv=none; b=JPfBhLIQFwXkic8quTM6NHiE9HyFQ3SyFp/+1tO/DD4hWsWRzdwICBuJUnsx5Wr36lLS9ChKZZwUDGZ2B3616DKItbqV1qHpIOLSd7e3ua3wBkw2xjuHMyuu+88Mb07M2joNsBsdnXZILeTEO7hkls+urTLbjLaBFIMwnwRAC4w=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1770216192; c=relaxed/simple;
	bh=5XsBD9a8thYfI+iHS224mgUk+7f323eD2TOA+Q6tl0Y=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=bMReRikFke2hiEdlIqo5fUIviLhfxqdr8kxS8PZ0FvQ0O0lW8JkFTh+oFv1UTRN5WsD4AVegq44iL8fhkpCfd6MG1IYMP4Rq7z4NlUGpT9h7zpz8PgkrrcTkqPjB+JHw+vgSJBLOM76vL1q/zmIRTrBCppLFZPwd/lgBHUK728M=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=mZWnzYJn; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03DFDC4CEF7;
	Wed,  4 Feb 2026 14:43:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1770216192;
	bh=5XsBD9a8thYfI+iHS224mgUk+7f323eD2TOA+Q6tl0Y=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=mZWnzYJnKgNHStPXHG9xR/AwHRv/dS6L40SNuGo6iWuCjnIN9ADfMJAMiMVMePSl1
	 09fBNugpEVVX3NOiRLzKD11ISyXL2DvpDDBkDoK8Y1liU6YEoa2LFPce0c0x9iPEVt
	 1t/UptJ7rfBRkiBnRI+CeMqkHh63pp/AY9PVzuNE=
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev,
	Suraj Gupta <suraj.gupta2@amd.com>,
	Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>,
	Folker Schwesinger <dev@folker-schwesinger.de>,
	Vinod Koul <vkoul@kernel.org>,
	Sasha Levin <sashal@kernel.org>
Subject: [PATCH 5.10 015/161] dmaengine: xilinx_dma: Fix uninitialized addr_width when "xlnx,addrwidth" property is missing
Date: Wed,  4 Feb 2026 15:37:58 +0100
Message-ID: <20260204143852.314173736@linuxfoundation.org>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <20260204143851.755002596@linuxfoundation.org>
References: <20260204143851.755002596@linuxfoundation.org>
User-Agent: quilt/0.69
X-stable: review
X-Patchwork-Hint: ignore
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-DKIM: signer='linuxfoundation.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: 0.4 (/)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://mxroutedocs.com/directadmin/spamfilters/
 ---
 Content analysis details:   (0.4 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                             blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: linuxfoundation.org]
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: 4

5.10-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Suraj Gupta <suraj.gupta2@amd.com>

[ Upstream commit c0732fe78728718c853ef8e7af5bbb05262acbd1 ]

When device tree lacks optional "xlnx,addrwidth" property, the addr_width
variable remained uninitialized with garbage values, causing incorrect
DMA mask configuration and subsequent probe failure. The fix ensures a
fallback to the default 32-bit address width when this property is missing.

Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
Fixes: b72db4005fe4 ("dmaengine: vdma: Add 64 bit addressing support to the driver")
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Reviewed-by: Folker Schwesinger <dev@folker-schwesinger.de>
Link: https://patch.msgid.link/20251021183006.3434495-1-suraj.gupta2@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/dma/xilinx/xilinx_dma.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 3ecf0109af2ba..12e9ba5b114db 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -128,6 +128,7 @@
 #define XILINX_MCDMA_MAX_CHANS_PER_DEVICE	0x20
 #define XILINX_DMA_MAX_CHANS_PER_DEVICE		0x2
 #define XILINX_CDMA_MAX_CHANS_PER_DEVICE	0x1
+#define XILINX_DMA_DFAULT_ADDRWIDTH		0x20
 
 #define XILINX_DMA_DMAXR_ALL_IRQ_MASK	\
 		(XILINX_DMA_DMASR_FRM_CNT_IRQ | \
@@ -2996,7 +2997,7 @@ static int xilinx_dma_probe(struct platform_device *pdev)
 	struct device_node *node = pdev->dev.of_node;
 	struct xilinx_dma_device *xdev;
 	struct device_node *child, *np = pdev->dev.of_node;
-	u32 num_frames, addr_width, len_width;
+	u32 num_frames, addr_width = XILINX_DMA_DFAULT_ADDRWIDTH, len_width;
 	int i, err;
 
 	/* Allocate and initialize the DMA engine structure */
@@ -3065,7 +3066,9 @@ static int xilinx_dma_probe(struct platform_device *pdev)
 
 	err = of_property_read_u32(node, "xlnx,addrwidth", &addr_width);
 	if (err < 0)
-		dev_warn(xdev->dev, "missing xlnx,addrwidth property\n");
+		dev_warn(xdev->dev,
+			 "missing xlnx,addrwidth property, using default value %d\n",
+			 XILINX_DMA_DFAULT_ADDRWIDTH);
 
 	if (addr_width > 32)
 		xdev->ext_addr = true;
-- 
2.51.0





From - Wed Feb 04 14:43:56 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-213405-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id mId4Fydbg2lchRMAYBR5ng
	(envelope-from <stable+bounces-213405-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Wed, 04 Feb 2026 14:43:51 +0000
Return-path: <stable+bounces-213405-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Wed, 04 Feb 2026 14:43:51 +0000
Received: from sto.lore.kernel.org ([172.232.135.74])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-213405-hi=josie.lol@vger.kernel.org>)
	id 1vne6g-000000063Lw-4A78
	for hi@josie.lol;
	Wed, 04 Feb 2026 14:43:51 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sto.lore.kernel.org (Postfix) with ESMTP id B6E453004637
	for <hi@josie.lol>; Wed,  4 Feb 2026 14:43:49 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 2047F40758D;
	Wed,  4 Feb 2026 14:43:48 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="PL1vwJFB"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 F1723280A3B;
	Wed,  4 Feb 2026 14:43:47 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1770216228; cv=none; b=U2wkicP/uIeViOCxN8tjYFGeV0CjBgTKoELsbPUWRba7rf/atRUqughJgA5KeNLiy3d2LrKMmkrRiIfjqJuGQ4XxsKUK97pUbH/HHc7xfRLE8sRKzsAs+7ItrJmNxuESpMU7kgiaXdcG/lRZVdKAXXNqoyS+NYfK6g2GOi5E7WQ=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1770216228; c=relaxed/simple;
	bh=ojvybpUOVABD/T8gQD28sGV2jGI5unZxtdSfJ9Gi6Fg=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=UTcbvZTcVpxjYN9NVZxP21XbNfcFo2I0c91p61TK3a+RrunEhGZ1RUMu7wBr+KWw6nWpKcQroOigyqsGs1p0rtVoNk0tc1GZaOyaU7fXGCKjXBOjjWRpZzo6we20DP1hp8KRkPPbQASJid4RbGe+OK3hb5+rO6Q8CRp+Q6Z4hFQ=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=PL1vwJFB; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 27224C4CEF7;
	Wed,  4 Feb 2026 14:43:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1770216227;
	bh=ojvybpUOVABD/T8gQD28sGV2jGI5unZxtdSfJ9Gi6Fg=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=PL1vwJFBVu4GDHNTSlZy5We19qE3t5DYbQYsIOzB+qzW9W3fzCIQlcNgjd4QaYJ0V
	 P5jysMTHmlns7upeo+e09BvcTIuRP+iWOT3XKQmARdHMTnjS7KH9f6/fdaIR9bkEwg
	 5qNf8nzc7r3yECGrtv3KBUeTFP8MXLkGkl7QKtEk=
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev,
	Filipe Manana <fdmanana@suse.com>,
	Qu Wenruo <wqu@suse.com>,
	David Sterba <dsterba@suse.com>,
	Sasha Levin <sashal@kernel.org>
Subject: [PATCH 5.10 004/161] btrfs: send: check for inline extents in range_is_hole_in_parent()
Date: Wed,  4 Feb 2026 15:37:47 +0100
Message-ID: <20260204143851.919366239@linuxfoundation.org>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <20260204143851.755002596@linuxfoundation.org>
References: <20260204143851.755002596@linuxfoundation.org>
User-Agent: quilt/0.69
X-stable: review
X-Patchwork-Hint: ignore
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-DKIM: signer='linuxfoundation.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: 0.4 (/)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://mxroutedocs.com/directadmin/spamfilters/
 ---
 Content analysis details:   (0.4 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                             blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: linuxfoundation.org]
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: 4

5.10-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Qu Wenruo <wqu@suse.com>

[ Upstream commit 08b096c1372cd69627f4f559fb47c9fb67a52b39 ]

Before accessing the disk_bytenr field of a file extent item we need
to check if we are dealing with an inline extent.
This is because for inline extents their data starts at the offset of
the disk_bytenr field. So accessing the disk_bytenr
means we are accessing inline data or in case the inline data is less
than 8 bytes we can actually cause an invalid
memory access if this inline extent item is the first item in the leaf
or access metadata from other items.

Fixes: 82bfb2e7b645 ("Btrfs: incremental send, fix unnecessary hole writes for sparse files")
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/btrfs/send.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index d86b4d13cae48..f144171ed6b7e 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -5892,6 +5892,8 @@ static int range_is_hole_in_parent(struct send_ctx *sctx,
 		extent_end = btrfs_file_extent_end(path);
 		if (extent_end <= start)
 			goto next;
+		if (btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE)
+			return 0;
 		if (btrfs_file_extent_disk_bytenr(leaf, fi) == 0) {
 			search_start = extent_end;
 			goto next;
-- 
2.51.0





From - Wed Feb 04 14:44:09 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-213395-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id 4EDxASlbg2nJ9RMAYBR5ng
	(envelope-from <stable+bounces-213395-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Wed, 04 Feb 2026 14:43:53 +0000
Return-path: <stable+bounces-213395-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Wed, 04 Feb 2026 14:43:53 +0000
Received: from sea.lore.kernel.org ([172.234.253.10])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-213395-hi=josie.lol@vger.kernel.org>)
	id 1vne6i-000000063N3-2KjJ
	for hi@josie.lol;
	Wed, 04 Feb 2026 14:43:53 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sea.lore.kernel.org (Postfix) with ESMTP id 6778F301177B
	for <hi@josie.lol>; Wed,  4 Feb 2026 14:43:17 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 0FFD3345CA5;
	Wed,  4 Feb 2026 14:43:16 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="NKj5oLDS"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 E1C1F1EA84;
	Wed,  4 Feb 2026 14:43:15 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1770216196; cv=none; b=bnQ8hyCgWG72s2mEnGfb3flYcZ4EMnrY11sKxqj5djRZxXjaiKSLmG3MBm3eEGRJlTi2Ge0Ta4rwFO2UXpmkQhadufmfZLQOqKQEc4orbF3MuHkwAHRSSI/Giv37YO/s1JaUWq04nmDM54Nk6xCTN7RGHg1V7AXzgqYctBN70tE=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1770216196; c=relaxed/simple;
	bh=m2ktMt47fVMyof6SBXrwkoWZ+Cu0+uhwjIWAlRYNlo0=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=gGiYrN+byAzjJDU18WaYFBh9xQuWMXSnQpKjeWg5X3wfxync7TwkVTLUsh7SooeASJPFbUXEKLxve0f1EOPyQ8cpYBObBNXt4yFmJXBB+tz8eny8kMShHD6XvouqL+utbesZTcaCYJRv8hFLr0mCAHtQkGgZZA7VZnCEykRqimI=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=NKj5oLDS; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18CBFC4CEF7;
	Wed,  4 Feb 2026 14:43:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1770216195;
	bh=m2ktMt47fVMyof6SBXrwkoWZ+Cu0+uhwjIWAlRYNlo0=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=NKj5oLDS1O/O+4mpHH2+oII2MVb+2XybMztzPGvHFAbQJAEyY8ZWQHZT0NeVfAHD6
	 f/opaU5Q5ZinFdvQctHxBpSOgWqYuFzFKDmSleBv8AZGZoO87kJxXVB816TFVpcKFf
	 8QOxH1t2PyF1AEO5xlroNkVf54pXSsEojV5GTwiQ=
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev,
	Dan Carpenter <dan.carpenter@linaro.org>,
	Amelie Delaunay <amelie.delaunay@foss.st.com>,
	Vinod Koul <vkoul@kernel.org>,
	Sasha Levin <sashal@kernel.org>
Subject: [PATCH 5.10 016/161] phy: stm32-usphyc: Fix off by one in probe()
her ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30F01365A1E;
	Mon, 23 Feb 2026 12:37:46 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1771850267; cv=none; b=JglqvgzFluiABUkcOCf+jTJI6qiEMEjeuCztjQeA0SNw5g2pYhZEsFls5avgE6Odyrptf97UEvFsa4Jg2gKaB1JwK5hthuVo8QhSHF+X1OsynAB5Pw7AcmJAvT0IjC2edYdwZXgGSfIUvV9NE9EjV2Sd4+0KvONMNOB+LDVcD7Q=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1771850267; c=relaxed/simple;
	bh=8FmYs+QrdSDFMbKC7QBfwAXPK2pJJB0FmB/uWUvKPnc=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=eIgLWyAuti+9De6574pUBDdlXZ31i+0LapzS/akSIQ+tPNohLqlKrVPxvL+796p0OtOamf/8Fgl/fiXdxLJ7X1FbwR/PlCxwlGwaJ+rcssEPQyDV97TwpsPGt56kmc1h4wKFXFpI2qVjX2CG69F9rwjv8MWXmuECrLS/7vp3wdc=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WOJ84LIB; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0998CC2BC9E;
	Mon, 23 Feb 2026 12:37:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1771850266;
	bh=8FmYs+QrdSDFMbKC7QBfwAXPK2pJJB0FmB/uWUvKPnc=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=WOJ84LIBNwGlaD8YoCJIe2RS1r4Xg7VHNPOF2YM9Ki84Q25tEIHa0mlvFcwq7cUXN
	 PptNKboPgj9OCh2r77JO57Ra38b1lSoiofOoEo0UHTPPFYO33w5w5+yw6g6G6N02EB
	 oCP0YrSgntGEttNrX7YB58tnX23aXDRFnNcwnZSOgCnSVQ9zU2KRn9ZvBJxokX/y4Y
	 b9LuAfNjsrgcRNPerc3uvCPK8zQ0uOgPq1ory/kDZN+YhleuJllZxWFGgH4vZJ0voF
	 N+kZ5dga6fQvNqWn75Fnl3NEFSWCRrX1zPoysPNXOSF0aFElnb0ZX337FsIBD7aldf
	 YL8W08SHB2oNg==
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev,
	stable@vger.kernel.org
Cc: Takashi Iwai <tiwai@suse.de>,
	Sasha Levin <sashal@kernel.org>,
	perex@perex.cz,
	tiwai@suse.com,
	linux-sound@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.19-5.15] ALSA: usb-audio: Add sanity check for OOB writes at silencing
Date: Mon, 23 Feb 2026 07:37:10 -0500
Message-ID: <20260223123738.1532940-5-sashal@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20260223123738.1532940-1-sashal@kernel.org>
References: <20260223123738.1532940-1-sashal@kernel.org>
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.19.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-DKIM: signer='kernel.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://docs.mxroute.com/docs/expert-spam-filtering.html
 ---
 Content analysis details:   (-1.2 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                             blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: msgid.link]
  0.0 URIBL_DBL_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to
                             dbl.spamhaus.org was blocked due to usage
                             of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [URIs: msgid.link]
  0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query
                              to zen.spamhaus.org was blocked due to
                             usage of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [172.234.253.10 listed in zen.spamhaus.org]
  0.0 URIBL_ZEN_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to
                             zen.spamhaus.org was blocked due to usage
                             of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [URIs: msgid.link]
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -0.1 DKIM_VALID_EF          Message has a valid DKIM or DK signature from
                             envelope-from domain
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: -11

From: Takashi Iwai <tiwai@suse.de>

[ Upstream commit fba2105a157fffcf19825e4eea498346738c9948 ]

At silencing the playback URB packets in the implicit fb mode before
the actual playback, we blindly assume that the received packets fit
with the buffer size.  But when the setup in the capture stream
differs from the playback stream (e.g. due to the USB core limitation
of max packet size), such an inconsistency may lead to OOB writes to
the buffer, resulting in a crash.

For addressing it, add a sanity check of the transfer buffer size at
prepare_silent_urb(), and stop the data copy if the received data
overflows.  Also, report back the transfer error properly from there,
too.

Note that this doesn't fix the root cause of the playback error
itself, but this merely covers the kernel Oops.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
Link: https://patch.msgid.link/20260216141209.1849200-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### What the commit fixes

This commit adds bounds checking to `prepare_silent_urb()` in the USB
audio driver to prevent **out-of-bounds memory writes** that cause a
**kernel panic/oops**. The bug occurs during implicit feedback mode when
silencing playback URB packets before actual playback begins. When the
capture stream has different (larger) packet sizes than the playback
stream (e.g., due to USB core max packet size limitations), the code
writes beyond the allocated transfer buffer, corrupting memory and
crashing the kernel.

### Bug severity

This is a **kernel crash/oops** triggered by real hardware. The bugzilla
report (bug #221076) documents:
- Hard system lockups / kernel panics on multiple platforms (Intel, AMD,
  Raspberry Pi 5)
- Reproducible with specific USB audio devices at high sample rates
  (352.8kHz/384kHz, 6-channel)
- The crash trace shows `memset_orig` called from `prepare_outbound_urb`
  → page fault on not-present page
- The regression was traced back to kernel 5.8.0, meaning it has
  affected users for years

### Code change analysis

The fix is small (22 insertions, 17 deletions, single file) and
surgical:

1. **Return type change**: `prepare_silent_urb()` changes from `void` to
   `int` to report errors
2. **Negative return check**: Checks if
   `snd_usb_endpoint_next_packet_size()` returns a negative error code
   before using the value
3. **Buffer bounds check**: `if (offs + length + extra >
   ctx->buffer_size) break;` — stops copying if data would overflow the
   buffer
4. **Error propagation**: Returns `-EPIPE` if nothing was written, `0`
   on success
5. **Caller updated**: `prepare_outbound_urb()` now returns the error
   from `prepare_silent_urb()` instead of ignoring it

### Stable kernel criteria assessment

- **Obviously correct**: Yes — adds bounds checking before memory
  writes, a straightforward safety measure
- **Fixes a real bug**: Yes — kernel oops/panic with real hardware,
  documented in bugzilla with crash traces
- **Small and contained**: Yes — 22 insertions/17 deletions in a single
  file, no API changes
- **No new features**: Correct — purely defensive checks
- **Risk**: Very low — the check only prevents writing beyond the
  buffer; normal operation is unchanged

### Dependencies

The commit modifies only `prepare_silent_urb()` and its caller in
`prepare_outbound_urb()`. The `ctx->buffer_size` field has been present
since the URB context structure was established. No prerequisite commits
appear needed.

### Verification

- Confirmed via the bugzilla report (bug #221076) that this is a real
  user-reported crash with kernel oops trace showing `memset_orig` page
  fault in `prepare_outbound_urb` call path
- The bug has been present since kernel 5.8.0 per user bisection,
  meaning all stable trees are affected
- Explored `snd_usb_endpoint_next_packet_size()` — confirmed it can
  return negative (`-EAGAIN`), which was not checked before this fix
- Confirmed `ctx->buffer_size` is set in `data_ep_set_params()` as
  `maxsize * packets`, and the transfer buffer is allocated to that size
  — so the bounds check is valid
- The commit is authored by Takashi Iwai (ALSA maintainer), providing
  high confidence in correctness
- The commit message explicitly states it covers a kernel Oops — a clear
  stable-worthy fix
- Commit touches only `sound/usb/endpoint.c` (1 file, small diff)

This is a textbook stable backport candidate: a small, surgical fix for
a kernel crash affecting real users, authored by the subsystem
maintainer, with low regression risk.

**YES**

 sound/usb/endpoint.c | 39 ++++++++++++++++++++++-----------------
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
index 27ade2aa16f5a..1eaf52d1ae9c7 100644
--- a/sound/usb/endpoint.c
+++ b/sound/usb/endpoint.c
@@ -275,8 +275,8 @@ static inline bool has_tx_length_quirk(struct snd_usb_audio *chip)
 	return chip->quirk_flags & QUIRK_FLAG_TX_LENGTH;
 }
 
-static void prepare_silent_urb(struct snd_usb_endpoint *ep,
-			       struct snd_urb_ctx *ctx)
+static int prepare_silent_urb(struct snd_usb_endpoint *ep,
+			      struct snd_urb_ctx *ctx)
 {
 	struct urb *urb = ctx->urb;
 	unsigned int offs = 0;
@@ -289,28 +289,34 @@ static void prepare_silent_urb(struct snd_usb_endpoint *ep,
 		extra = sizeof(packet_length);
 
 	for (i = 0; i < ctx->packets; ++i) {
-		unsigned int offset;
-		unsigned int length;
-		int counts;
-
-		counts = snd_usb_endpoint_next_packet_size(ep, ctx, i, 0);
-		length = counts * ep->stride; /* number of silent bytes */
-		offset = offs * ep->stride + extra * i;
-		urb->iso_frame_desc[i].offset = offset;
+		int length;
+
+		length = snd_usb_endpoint_next_packet_size(ep, ctx, i, 0);
+		if (length < 0)
+			return length;
+		length *= ep->stride; /* number of silent bytes */
+		if (offs + length + extra > ctx->buffer_size)
+			break;
+		urb->iso_frame_desc[i].offset = offs;
 		urb->iso_frame_desc[i].length = length + extra;
 		if (extra) {
 			packet_length = cpu_to_le32(length);
-			memcpy(urb->transfer_buffer + offset,
+			memcpy(urb->transfer_buffer + offs,
 			       &packet_length, sizeof(packet_length));
+			offs += extra;
 		}
-		memset(urb->transfer_buffer + offset + extra,
+		memset(urb->transfer_buffer + offs,
 		       ep->silence_value, length);
-		offs += counts;
+		offs += length;
 	}
 
-	urb->number_of_packets = ctx->packets;
-	urb->transfer_buffer_length = offs * ep->stride + ctx->packets * extra;
+	if (!offs)
+		return -EPIPE;
+
+	urb->number_of_packets = i;
+	urb->transfer_buffer_length = offs;
 	ctx->queued = 0;
+	return 0;
 }
 
 /*
@@ -332,8 +338,7 @@ static int prepare_outbound_urb(struct snd_usb_endpoint *ep,
 		if (data_subs && ep->prepare_data_urb)
 			return ep->prepare_data_urb(data_subs, urb, in_stream_lock);
 		/* no data provider, so send silence */
-		prepare_silent_urb(ep, ctx);
-		break;
+		return prepare_silent_urb(ep, ctx);
 
 	case SND_USB_ENDPOINT_TYPE_SYNC:
 		if (snd_usb_get_speed(ep->chip->dev) >= USB_SPEED_HIGH) {
-- 
2.51.0



From - Mon Feb 23 12:40:15 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-217757-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id sMaxHatKnGlkoBUAYBR5ng
	(envelope-from <stable+bounces-217757-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Mon, 23 Feb 2026 12:40:11 +0000
Return-path: <stable+bounces-217757-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Mon, 23 Feb 2026 12:40:11 +0000
Received: from sto.lore.kernel.org ([172.232.135.74])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-217757-hi=josie.lol@vger.kernel.org>)
	id 1vuVEQ-00000006wwG-2eLb
	for hi@josie.lol;
	Mon, 23 Feb 2026 12:40:11 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sto.lore.kernel.org (Postfix) with ESMTP id E5490304DEA4
	for <hi@josie.lol>; Mon, 23 Feb 2026 12:38:41 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 88BF3366DDE;
	Mon, 23 Feb 2026 12:38:06 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Dxq2xMUE"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 6242036654A;
	Mon, 23 Feb 2026 12:38:06 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1771850286; cv=none; b=rals67YXxfisVNxBtyBzPlpAZ2nk1VlePf/WN/E7OoF9+5gHZF3lYusQ1XNgr7CLMt00UXYpEXkxylk0dyFpkwdZ231hS8BXAVIZJ241WHQDzmK843aU7cV6G9UPbsG6ufQC1Dq6TXL4QChGgOX8ksCN7ERn0ajkWqedqIF8Y+I=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1771850286; c=relaxed/simple;
	bh=EfL1zGl01oo4GS5HNkMgV5OVgLXxYcXRoLCBrmlcPQQ=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=libWlfT2u/2mvZCf+SzuDh6c+siOYJuA1MtQlJ+eI9e5DD3PGyLWQTvRPIv8zjickHWWrA+bv98doA0GStO8AmkMyfxQS0Aqb7iFrwphuEQl3IX3HuoE3ErhoHJJ/tvL4Yslh+m3h0NunL/w/2g+G+8CkQ/NqQNMOBkgnG4oZE0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Dxq2xMUE; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DAABC2BC86;
	Mon, 23 Feb 2026 12:38:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1771850286;
	bh=EfL1zGl01oo4GS5HNkMgV5OVgLXxYcXRoLCBrmlcPQQ=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=Dxq2xMUEYjAP/TINOt3M+vG1ghNlYHGqZr060RjoAFlI/Fusv6dCUJwN5XKwBepyI
	 PfDeeFPQUzm0f7aQwnDn2iXaufuEXQgDpp6bvgTUKItygIJ6XhcIYU42neJBLC/1fX
	 HE0iZhSUKiw4QpMHVOUdDImqGuVXURm5eb/ySKYKyZbdo88GPBNX5sj3q78eHxM+qZ
	 NqSU8rSE0pBPcyburmBqux65U3EfPLxDCfjYydDX5nw+xsrXY3kHXSHFK4Pv1tYg4G
	 qnRZCSFTmlgWMpfrRV18oinWygTgAexv52YGJ8e3WsKez/yjxz23uCJdYXAOIG4/ZL
	 G16nAeB1tC/5A==
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev,
	stable@vger.kernel.org
Cc: Qu Wenruo <wqu@suse.com>,
	Christoph Hellwig <hch@lst.de>,
	David Sterba <dsterba@suse.com>,
	Sasha Levin <sashal@kernel.org>,
	clm@fb.com,
	linux-btrfs@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.19] btrfs: do not ASSERT() when the fs flips RO inside btrfs_repair_io_failure()
Date: Mon, 23 Feb 2026 07:37:23 -0500
Message-ID: <20260223123738.1532940-18-sashal@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20260223123738.1532940-1-sashal@kernel.org>
References: <20260223123738.1532940-1-sashal@kernel.org>
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.19.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-DKIM: signer='kernel.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://docs.mxroute.com/docs/expert-spam-filtering.html
 ---
 Content analysis details:   (-1.2 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                             blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: qemu.org]
  0.0 URIBL_DBL_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to
                             dbl.spamhaus.org was blocked due to usage
                             of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [URIs: qemu.org]
  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [172.232.135.74 listed in list.dnswl.org]
  0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query
                              to zen.spamhaus.org was blocked due to
                             usage of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [172.232.135.74 listed in zen.spamhaus.org]
  0.0 URIBL_ZEN_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to
                             zen.spamhaus.org was blocked due to usage
                             of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [URIs: qemu.org]
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -0.1 DKIM_VALID_EF          Message has a valid DKIM or DK signature from
                             envelope-from domain
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: -11

From: Qu Wenruo <wqu@suse.com>

[ Upstream commit 8ceaad6cd6e7fa5f73b0b2796a2e85d75d37e9f3 ]

[BUG]
There is a bug report that when btrfs hits ENOSPC error in a critical
path, btrfs flips RO (this part is expected, although the ENOSPC bug
still needs to be addressed).

The problem is after the RO flip, if there is a read repair pending, we
can hit the ASSERT() inside btrfs_repair_io_failure() like the following:

  BTRFS info (device vdc): relocating block group 30408704 flags metadata|raid1
  ------------[ cut here ]------------
  BTRFS: Transaction aborted (error -28)
  WARNING: fs/btrfs/extent-tree.c:3235 at __btrfs_free_extent.isra.0+0x453/0xfd0, CPU#1: btrfs/383844
  Modules linked in: kvm_intel kvm irqbypass
  [...]
  ---[ end trace 0000000000000000 ]---
  BTRFS info (device vdc state EA): 2 enospc errors during balance
  BTRFS info (device vdc state EA): balance: ended with status: -30
  BTRFS error (device vdc state EA): parent transid verify failed on logical 30556160 mirror 2 wanted 8 found 6
  BTRFS error (device vdc state EA): bdev /dev/nvme0n1 errs: wr 0, rd 0, flush 0, corrupt 10, gen 0
  [...]
  assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/bio.c:938
  ------------[ cut here ]------------
  assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/bio.c:938
  kernel BUG at fs/btrfs/bio.c:938!
  Oops: invalid opcode: 0000 [#1] SMP NOPTI
  CPU: 0 UID: 0 PID: 868 Comm: kworker/u8:13 Tainted: G        W        N  6.19.0-rc6+ #4788 PREEMPT(full)
  Tainted: [W]=WARN, [N]=TEST
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
  Workqueue: btrfs-endio simple_end_io_work
  RIP: 0010:btrfs_repair_io_failure.cold+0xb2/0x120
  RSP: 0000:ffffc90001d2bcf0 EFLAGS: 00010246
  RAX: 0000000000000051 RBX: 0000000000001000 RCX: 0000000000000000
  RDX: 0000000000000000 RSI: ffffffff8305cf42 RDI: 00000000ffffffff
  RBP: 0000000000000002 R08: 00000000fffeffff R09: ffffffff837fa988
  R10: ffffffff8327a9e0 R11: 6f69747265737361 R12: ffff88813018d310
  R13: ffff888168b8a000 R14: ffffc90001d2bd90 R15: ffff88810a169000
  FS:  0000000000000000(0000) GS:ffff8885e752c000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  ------------[ cut here ]------------

[CAUSE]
The cause of -ENOSPC error during the test case btrfs/124 is still
unknown, although it's known that we still have cases where metadata can
be over-committed but can not be fulfilled correctly, thus if we hit
such ENOSPC error inside a critical path, we have no choice but abort
the current transaction.

This will mark the fs read-only.

The problem is inside the btrfs_repair_io_failure() path that we require
the fs not to be mount read-only. This is normally fine, but if we are
doing a read-repair meanwhile the fs flips RO due to a critical error,
we can enter btrfs_repair_io_failure() with super block set to
read-only, thus triggering the above crash.

[FIX]
Just replace the ASSERT() with a proper return if the fs is already
read-only.

Reported-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/linux-btrfs/20260126045555.GB31641@lst.de/
Tested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The same ASSERT exists in v6.1 too (in extent_io.c instead of bio.c).
The bug is present across all stable trees.

## Analysis

### What problem does this commit solve?

This commit fixes a **kernel BUG/crash** (not just a warning) that
occurs when:
1. The btrfs filesystem encounters a critical error (e.g., ENOSPC in a
   critical path)
2. The filesystem flips to read-only mode (transaction abort)
3. Meanwhile, a concurrent read-repair operation calls
   `btrfs_repair_io_failure()`
4. The ASSERT checks `!(fs_info->sb->s_flags & SB_RDONLY)` and fails
5. Since btrfs's `ASSERT()` macro calls `BUG()`, this causes a kernel
   oops/crash

The crash is confirmed by the stack trace in the commit message showing
`kernel BUG at fs/btrfs/bio.c:938!`.

### Does it meet stable kernel rules?

1. **Obviously correct and tested**: Yes. The fix replaces an ASSERT
   (which calls BUG()) with a graceful `return 0` when the filesystem is
   read-only. It has `Tested-by: Christoph Hellwig` and `Reviewed-by:
   David Sterba` (btrfs maintainer).

2. **Fixes a real bug**: Yes. A kernel BUG/crash is triggered. The bug
   report is linked and comes from Christoph Hellwig, a prominent kernel
   developer.

3. **Fixes an important issue**: Yes. This is a kernel crash (oops via
   BUG()). If a filesystem encounters a critical error and goes RO, a
   concurrent read-repair shouldn't crash the entire system.

4. **Small and contained**: Yes. The change removes one line
   (`ASSERT(...)`) and adds a 4-line `if (unlikely(sb_rdonly(...)))
   return 0;` check. Total: ~6 lines changed in one file.

5. **Does NOT introduce new features**: Correct. It only changes error
   handling.

### Risk vs Benefit

- **Risk**: Extremely low. Replacing a crash (BUG()) with a graceful
  return (0 = success, skip repair) is safe. If the filesystem is
  already RO, skipping the repair write is correct behavior — you can't
  write to a RO filesystem anyway.
- **Benefit**: High. Prevents kernel crash in a race condition that real
  users hit (reported by Christoph Hellwig during btrfs/124 test).

### Backport considerations

The function signature has changed significantly across versions:
- **v6.6**: Uses `struct page *page` parameter — different signature but
  the ASSERT is identical
- **v6.12**: Uses `struct folio *folio` parameter — different signature
  but the ASSERT is identical
- **Current**: Uses `const phys_addr_t paddrs[]` parameter

However, the **fix itself** (remove ASSERT, add `if (sb_rdonly(...))
return 0`) is signature-independent and applies to all versions. A minor
adaptation to the surrounding context will be needed for each stable
tree, but the core fix is trivial.

### Verification

- **Verified**: The ASSERT macro in btrfs calls `BUG()` (confirmed in
  `fs/btrfs/messages.h` lines 139-152)
- **Verified**: The buggy ASSERT exists in v6.12 and v6.6 stable trees
  (checked via `git show v6.12:fs/btrfs/bio.c` and `git show
  v6.6:fs/btrfs/bio.c`)
- **Verified**: The buggy ASSERT also exists in v6.1 (in
  `fs/btrfs/extent_io.c` rather than `bio.c`, function named
  `repair_io_failure`)
- **Verified**: The function has two callers: `btrfs_end_repair_bio()`
  (bio.c) and `btrfs_repair_eb_io_failure()` (disk-io.c), both in I/O
  completion paths that can race with filesystem RO transitions
- **Verified**: The commit has `Tested-by: Christoph Hellwig`,
  `Reviewed-by: David Sterba`, and `Reported-by: Christoph Hellwig` with
  a link to the bug report
- **Verified**: The fix is a clean 6-line change — remove ASSERT, add
  early return with comment
- **Verified**: The function signature differs across stable trees (page
  vs folio vs phys_addr_t), but the fix concept (remove ASSERT, add
  sb_rdonly check) is identical and straightforward to adapt

This is a textbook stable backport candidate: a small, well-reviewed fix
for a kernel crash in a race condition, reported by a trusted developer,
in a widely-used filesystem. The fix is obviously correct — when the fs
is RO, there's nothing to repair and crashing is worse than skipping.

**YES**

 fs/btrfs/bio.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/bio.c b/fs/btrfs/bio.c
index fa1d321a2fb83..45bd3c3b6d793 100644
--- a/fs/btrfs/bio.c
+++ b/fs/btrfs/bio.c
@@ -935,7 +935,6 @@ int btrfs_repair_io_failure(struct btrfs_fs_info *fs_info, u64 ino, u64 fileoff,
 	struct bio *bio = NULL;
 	int ret = 0;
 
-	ASSERT(!(fs_info->sb->s_flags & SB_RDONLY));
 	BUG_ON(!mirror_num);
 
 	/* Basic alignment checks. */
@@ -947,6 +946,13 @@ int btrfs_repair_io_failure(struct btrfs_fs_info *fs_info, u64 ino, u64 fileoff,
 	ASSERT(step <= length);
 	ASSERT(is_power_of_2(step));
 
+	/*
+	 * The fs either mounted RO or hit critical errors, no need
+	 * to continue repairing.
+	 */
+	if (unlikely(sb_rdonly(fs_info->sb)))
+		return 0;
+
 	if (btrfs_repair_one_zone(fs_info, logical))
 		return 0;
 
-- 
2.51.0



From - Mon Feb 23 12:40:23 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-217753-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id 2NRpNLJKnGltFxkAYBR5ng
	(envelope-from <stable+bounces-217753-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Mon, 23 Feb 2026 12:40:18 +0000
Return-path: <stable+bounces-217753-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Mon, 23 Feb 2026 12:40:19 +0000
Received: from tor.lore.kernel.org ([172.105.105.114])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-217753-hi=josie.lol@vger.kernel.org>)
	id 1vuVEY-00000006xCu-20Bn
	for hi@josie.lol;
	Mon, 23 Feb 2026 12:40:18 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by tor.lore.kernel.org (Postfix) with ESMTP id A60783073858
	for <hi@josie.lol>; Mon, 23 Feb 2026 12:38:20 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id EE843366838;
	Mon, 23 Feb 2026 12:38:00 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BSXP/k2s"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 C8C51366835;
	Mon, 23 Feb 2026 12:38:00 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1771850280; cv=none; b=BuIqwXbQbEiyEAZbyBt4JvW+pnDOdANLKjV5obyXHPHy3145hb8S/+VgaFyCrd7IdvruQAA7AcuISwefpf1mjiZmmpO6w+S+L5IU+uak1s9MFvK8ZYq4dLgBoFz1FEHhHxwJHcwARGqIh9rVRCICiZnjBLWXGDx9+j5wMLo6sss=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1771850280; c=relaxed/simple;
	bh=iHZa8nYe42r2IjJzinLnQVMLFp3VrGSWpay58wvZsmw=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=mY20Rys+LgYJHALLNvW4iC9SP2obtC/P6+z/r0Pvm2Y3xku6XayVbLrws3QKv/KUpMBeMiUSKfi10dI07zFrPZGeQFEK0zJFhHjufLQagQCyZVKMwZk0c/Pxf14YGfmy+mXQFvFLrJHFRS8jFISAgNkB+4YTRdmxMtyf1yvGyyg=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BSXP/k2s; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2758BC4AF0C;
	Mon, 23 Feb 2026 12:37:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1771850280;
	bh=iHZa8nYe42r2IjJzinLnQVMLFp3VrGSWpay58wvZsmw=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=BSXP/k2sWKkXL0NuDeNI7dhVQSMrgkG2/+kBnm33XygN2m5TrOGFCFkXc+TBLrfpW
	 W8BndV/+jMANV0wfaBuJ9zCjWTuFT66y7z33tOPzC57gVhqCQzBA9CaCmc7o9MG9NB
	 SIaWLAbdot1KfZrnjT/fQYf50QX2+wXDdQZfarF22z4gf24Gkh/V1rdqbeX/L4aJ6a
	 cCQHDthNLeq5HOGAaBVuqpU/76DlcD8/oCT6rVWjw9KrV7wQaeNexerchKCTY/pz3i
	 cWd55/rdVomjGn54VgeqXcSbGlRHwGRbsDuIs6MXoCB7WDrXUPIGJZU904UlwrCdS7
	 +H+kBlOjQaWkQ==
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev,
	stable@vger.kernel.org
Cc: Victor Zhao <Victor.Zhao@amd.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	Sasha Levin <sashal@kernel.org>,
	christian.koenig@amd.com,
	airlied@gmail.com,
	simona@ffwll.ch,
	amd-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.19-6.18] drm/amdgpu: avoid sdma ring reset in sriov
Date: Mon, 23 Feb 2026 07:37:19 -0500
Message-ID: <20260223123738.1532940-14-sashal@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20260223123738.1532940-1-sashal@kernel.org>
References: <20260223123738.1532940-1-sashal@kernel.org>
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.19.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-DKIM: signer='kernel.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://docs.mxroute.com/docs/expert-spam-filtering.html
 ---
 Content analysis details:   (-1.2 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query
                              to zen.spamhaus.org was blocked due to
                             usage of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [172.105.105.114 listed in zen.spamhaus.org]
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -0.1 DKIM_VALID_EF          Message has a valid DKIM or DK signature from
                             envelope-from domain
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: -11

From: Victor Zhao <Victor.Zhao@amd.com>

[ Upstream commit 5cc7bbd9f1b74d9fe2f7ac08d6ba0477e8d2d65f ]

sdma ring reset is not supported in SRIOV. kfd driver does not check
reset mask, and could queue sdma ring reset during unmap_queues_cpsch.

Avoid the ring reset for sriov.

Signed-off-by: Victor Zhao <Victor.Zhao@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The background task completed but my analysis is already finished. The
result would show the same finding I already verified — that
`amdgpu_sdma_reset_engine` was introduced in the v6.15 cycle.

My final answer remains **YES** — this is a small, correct bug fix for
SR-IOV environments that prevents SDMA scheduler work queues from being
left in a stopped state.

 drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
index 8b8a04138711c..321310ba2c08e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
@@ -558,6 +558,9 @@ int amdgpu_sdma_reset_engine(struct amdgpu_device *adev, uint32_t instance_id,
 	struct amdgpu_ring *gfx_ring = &sdma_instance->ring;
 	struct amdgpu_ring *page_ring = &sdma_instance->page;
 
+	if (amdgpu_sriov_vf(adev))
+		return -EOPNOTSUPP;
+
 	mutex_lock(&sdma_instance->engine_reset_mutex);
 
 	if (!caller_handles_kernel_queues) {
-- 
2.51.0



From - Mon Feb 23 12:40:27 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-217745-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id SNQyKbVKnGltFxkAYBR5ng
	(envelope-from <stable+bounces-217745-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Mon, 23 Feb 2026 12:40:21 +0000
Return-path: <stable+bounces-217745-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Mon, 23 Feb 2026 12:40:21 +0000
Received: from sea.lore.kernel.org ([172.234.253.10])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-217745-hi=josie.lol@vger.kernel.org>)
	id 1vuVEa-00000006xEo-4C2m
	for hi@josie.lol;
	Mon, 23 Feb 2026 12:40:21 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sea.lore.kernel.org (Postfix) with ESMTP id 3D4DD30B54C7
	for <hi@josie.lol>; Mon, 23 Feb 2026 12:37:53 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 0036F366554;
	Mon, 23 Feb 2026 12:37:49 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PGqkAMqO"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 CE6EF365A02;
	Mon, 23 Feb 2026 12:37:48 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1771850268; cv=none; b=p7H4fChwE8y22hzDjiVtHSOFGxdjs/ORLKK44KqFP42hDSuZP+lYWaXZjLuDIAcl1/au+hQfl/oISA8yoNcm92ObGozOXNogtzhpw01os6+/G3Zx4QKboJ9KOAk1MnsIysMzNu+5Vl3SAEY+RkMvfcpnvYCnF4N1jKzJRMk+pKc=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1771850268; c=relaxed/simple;
	bh=ieO3IDaCxW655UojJOwVdh3Cqjs3Mef/DOUYYLZgQfY=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=Mj5P7aUaWneaFMd5AVJCtk0QuVBoEhgGynK0EaYA5ms2RjAfvMEVDY0DzDTNPV//W4Sv26h2LNLRRqvQdZYcZPb27WevDMuKeJ5K/kw/GS/BkltuvXpu2KI0BgEj7rwt2GRhFLTeR2g/YqfJhqZbMYDbdcQNHknAjLXhf2W+QAI=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PGqkAMqO; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C854C116D0;
	Mon, 23 Feb 2026 12:37:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1771850268;
	bh=ieO3IDaCxW655UojJOwVdh3Cqjs3Mef/DOUYYLZgQfY=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=PGqkAMqOuiB6v5WERJJ25jDW7mmx+7GSfSp3/2YybdIlEzVUW5V6AIRqtwMRxWcqO
	 YlJLSN+bO8LvxKT+NQ8RP4NXBUyr/NpwFjg0zqOWUs/UdTxW2B7a/7f/0UgYgdWIh8
	 XyUNEgcHe1AYzazA5aBIxIFzYem20IITCKLrQzXK7OIEoWorLp7rpJ5xoPfBbkY0p9
	 jSiLKVtsk/tKbLfR/xf4BoiHg1Yufh7vymI59xPV9FEz5N47hnn//JHAJFJXEFZgdo
	 84MQxiaiIjEkDTZ12dkfzCf65iCAMLKx/bpQqAfR/1fYz+fn/Y2f4jqNr28UyHAqC+
	 MRSYZu76UkpGw==
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev,
	stable@vger.kernel.org
Cc: Tom Chung <chiahsuan.chung@amd.com>,
	Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>,
	Wayne Lin <wayne.lin@amd.com>,
	Daniel Wheeler <daniel.wheeler@amd.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	Sasha Levin <sashal@kernel.org>,
	harry.wentland@amd.com,
	sunpeng.li@amd.com,
	christian.koenig@amd.com,
	airlied@gmail.com,
	simona@ffwll.ch,
	amd-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.19-6.12] drm/amd/display: Fix system resume lag issue
Date: Mon, 23 Feb 2026 07:37:11 -0500
Message-ID: <20260223123738.1532940-6-sashal@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20260223123738.1532940-1-sashal@kernel.org>
References: <20260223123738.1532940-1-sashal@kernel.org>
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.19.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-DKIM: signer='kernel.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://docs.mxroute.com/docs/expert-spam-filtering.html
 ---
 Content analysis details:   (-1.2 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [172.234.253.10 listed in list.dnswl.org]
  0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query
                              to zen.spamhaus.org was blocked due to
                             usage of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [172.234.253.10 listed in zen.spamhaus.org]
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -0.1 DKIM_VALID_EF          Message has a valid DKIM or DK signature from
                             envelope-from domain
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: -11

From: Tom Chung <chiahsuan.chung@amd.com>

[ Upstream commit 64c94cd9be2e188ed07efeafa6a109bce638c967 ]

[Why]
System will try to apply idle power optimizations setting during
system resume. But system power state is still in D3 state, and
it will cause the idle power optimizations command not actually
to be sent to DMUB and cause some platforms to go into IPS.

[How]
Set power state to D0 first before calling the
dc_dmub_srv_apply_idle_power_optimizations(dm->dc, false)

Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Wayne Lin <wayne.lin@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Good. Now I have all the information needed for my analysis.

---

## Analysis

### 1. Commit Message Analysis

The commit clearly describes a **system resume lag issue** on AMD
display platforms with IPS (Idle Power States) support. The commit is
structured with `[Why]` and `[How]` sections explaining the root cause
and fix:

- **Root Cause**: During system resume,
  `dc_dmub_srv_apply_idle_power_optimizations(dm->dc, false)` is called
  to disable idle power optimizations, but at that point the DMUB power
  state is still D3 (suspended). The DMUB firmware won't execute
  commands when in D3 state, so the idle power optimization disable
  command silently fails, causing some platforms to incorrectly enter
  IPS during resume.
- **Fix**: Set DMUB power state to D0 *before* calling the idle power
  optimizations command.

### 2. Code Change Analysis

The change is **+10 lines** in a single file. It adds:
1. `dc_dmub_srv_set_power_state(dm->dc->ctx->dmub_srv,
   DC_ACPI_CM_POWER_STATE_D0)` — sets DMUB to active power state before
   sending commands
2. Mutex locking around the operation (`dm->dc_lock`) for the non-reset
   resume path
3. The `amdgpu_in_reset()` check for mutex matches the existing pattern
   in the reset path (which already holds the lock)

The fix is clearly correct: looking at line 3559 of the current code,
the normal (non-IPS-early) resume path already calls
`dc_dmub_srv_set_power_state(D0)` before other operations. The early IPS
block was simply missing this prerequisite call.

### 3. Bug Severity

This is a **real user-visible bug** — system resume lag/hang on AMD
platforms with IPS support (DCN35+ hardware, e.g., AMD Ryzen mobile
APUs). This affects:
- Laptop users doing S3/S4 suspend/resume
- The fix prevents displays from being stuck/lagging after system resume
- Tested-by Daniel Wheeler (AMD) confirms hardware validation

### 4. Scope and Risk

- **Very small**: Only 10 lines added to a single file
- **Surgically targeted**: Only affects the early IPS power optimization
  block in `dm_resume()`
- **Pattern consistent**: The fix follows the exact same pattern used in
  the GPU-reset resume path (line 3500) and the normal resume path (line
  3559), both of which already call `dc_dmub_srv_set_power_state(D0)`
  first
- **Well-reviewed**: Reviewed by Nicholas Kazlauskas (AMD display
  expert), Tested by Daniel Wheeler (AMD QA), Signed-off by Wayne Lin
  and Alex Deucher (AMD display maintainer)
- **Low regression risk**: Adding D0 power state before a command is
  purely correctional — the command already expected D0 state

### 5. Dependencies

- `dc_dmub_srv_set_power_state()` was introduced in commit
  `0f657938e4345` (v6.8)
- The buggy `dc_dmub_srv_apply_idle_power_optimizations()` call in
  `dm_resume` was added around v6.9
- The `dm->dc_lock` mutex has existed since the display manager was
  created
- **No missing dependencies** — all required functions exist in v6.9+
  stable trees

### 6. Stable Tree Applicability

The fix applies to kernels **v6.9+** where the IPS check in `dm_resume`
exists. The code is self-contained and should apply cleanly to recent
stable trees (6.12.y, 6.6.y may need checking for ips_support code).

### Verification

- Verified the exact diff via `git diff 64c94cd9be2e1^..64c94cd9be2e1`:
  confirms +10 line change, single file
- Verified `dc_dmub_srv_set_power_state()` implementation at
  `dc_dmub_srv.c:1572-1585`: simple power state setter, calls
  `dmub_srv_set_power_state()`
- Verified the function was introduced in commit `0f657938e4345` (first
  in v6.8-rc1) via `git tag --contains`
- Verified the buggy IPS check (`ips_support` +
  `apply_idle_power_optimizations` in `dm_resume`) was added around v6.9
  via `git tag --contains 60818ed76577c`
- Verified `dm->dc_lock` mutex exists at `amdgpu_dm.h:446`
- Verified the normal resume path already calls
  `dc_dmub_srv_set_power_state(D0)` at line 3559, confirming the fix
  follows the established pattern
- Verified the GPU-reset resume path also calls
  `dc_dmub_srv_set_power_state(D0)` at line 3500, same pattern
- Could NOT verify via lore.kernel.org whether there are known
  regressions from this fix (unverified, but low concern given AMD
  testing)

### Conclusion

This is a clear, well-tested bug fix for a real user-visible issue
(system resume lag/hang on AMD IPS-capable platforms). The fix is small
(+10 lines), surgical, follows established patterns in the same
function, has been reviewed and tested by AMD engineers, and has no
feature additions. It meets all stable kernel criteria.

**YES**

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index a72394b05ab02..e004fc3893edf 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3468,7 +3468,17 @@ static int dm_resume(struct amdgpu_ip_block *ip_block)
 	struct dc_commit_streams_params commit_params = {};
 
 	if (dm->dc->caps.ips_support) {
+		if (!amdgpu_in_reset(adev))
+			mutex_lock(&dm->dc_lock);
+
+		/* Need to set POWER_STATE_D0 first or it will not execute
+		 * idle_power_optimizations command to DMUB.
+		 */
+		dc_dmub_srv_set_power_state(dm->dc->ctx->dmub_srv, DC_ACPI_CM_POWER_STATE_D0);
 		dc_dmub_srv_apply_idle_power_optimizations(dm->dc, false);
+
+		if (!amdgpu_in_reset(adev))
+			mutex_unlock(&dm->dc_lock);
 	}
 
 	if (amdgpu_in_reset(adev)) {
-- 
2.51.0



From - Mon Feb 23 12:40:39 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-217754-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id 0ECyAMNKnGlN3BcAYBR5ng
	(envelope-from <stable+bounces-217754-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Mon, 23 Feb 2026 12:40:35 +0000
Return-path: <stable+bounces-217754-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Mon, 23 Feb 2026 12:40:35 +0000
Received: from tor.lore.kernel.org ([172.105.105.114])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-217754-hi=josie.lol@vger.kernel.org>)
	id 1vuVEo-00000006xda-0NEk
	for hi@josie.lol;
	Mon, 23 Feb 2026 12:40:34 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by tor.lore.kernel.org (Postfix) with ESMTP id 6995D307D81E
	for <hi@josie.lol>; Mon, 23 Feb 2026 12:38:24 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id D3C6336683F;
	Mon, 23 Feb 2026 12:38:01 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VOJkvleo"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 AD9EB36606F;
	Mon, 23 Feb 2026 12:38:01 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1771850281; cv=none; b=DFNyk1g5O9YYq7x/RtnV54NlTpFbveAwdWy6pfpGCQakeyK6fdhSnAXy1AUSZKi6et7k7mhpCoI2J76SJMHz/A3irlQiZIR4fuHPdDnqUxlyGa6AzzSTryh3I8jsEJ5PkNFFKrFO2Z6QF+HA/iPWFIXcckvMsRCHWYmZqKynxrU=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1771850281; c=relaxed/simple;
	bh=joVrSiLBOUSMSp4SN28ckyepXrgflCGpqwb34ECohbQ=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=ML2SNyQs6QbQSfZeq9T0FZS0rKb6Y1S3lRU2UhrLx2VOI0XnQb7WMeykcP0EX9gnexJGDsuyZewpqePCWRyC23cfhrH+yIKHGX+aS/RhjooTTB7TdkJ51Dz/nOLATK0OBjDIGLamjO9QzuRdmNsKuZG56fs2DdikzSRwHg5IjxU=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VOJkvleo; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D01FC2BCB0;
	Mon, 23 Feb 2026 12:38:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1771850281;
	bh=joVrSiLBOUSMSp4SN28ckyepXrgflCGpqwb34ECohbQ=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=VOJkvleoRyxxJBgKnCSjrLlKEqO/Bae44WRozp1sNzRfZW+sdkxINKKjZLxwzUGKW
	 DfQwFx1eSvT+tFLn5ridssspwPHqHJEAnH1Y7cGywaMJQH4rdxxX+7tnRXzRsTLWSm
	 hPERjm97vdZkDt9aT2qTyhnc9C/Ng3V4m+ay0mYa/PJtB2sOj9E/xoJWQ9pbJdfS0X
	 8QWiNuZ+Q30wsBy2sei12Jv5OL9MQu3amUXh3DT3s+DzoYO66eLMv2pjR48ercLbNQ
	 FsF6+fB9T+ifIEFyhofE8cafDUWI9oK8Upa7nXGnK7ePT/T1PHT4kK8J32HJLqpqyb
	 mcZIYaTUKrK3Q==
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev,
	stable@vger.kernel.org
Cc: Fabian Godehardt <fg@emlix.com>,
	Mark Brown <broonie@kernel.org>,
	Sasha Levin <sashal@kernel.org>,
	linux-spi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.19-6.12] spi: spidev: fix lock inversion between spi_lock and buf_lock
Date: Mon, 23 Feb 2026 07:37:20 -0500
Message-ID: <20260223123738.1532940-15-sashal@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20260223123738.1532940-1-sashal@kernel.org>
References: <20260223123738.1532940-1-sashal@kernel.org>
Precedence: bulk
X-Maili