Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7C546220698; Sat, 12 Sep 2026 13:18:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789219113; cv=none; b=jT/AvCEpDvUEDEA9bstKwkoeVJs7oeAHNpvXL0wLWOaPSipMt/FdLYHwZFnWKp/O16OVF2weHhbLxmMg2gYxN6ofkaz/8e+qVsBQVOS14WFZ59gUpTjYtuqYtNF24orP1b4UgMweyoXzaEuu3Mf+8NN5PE5dxQhPweNLbOv3g0g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789219113; c=relaxed/simple; bh=d8qB6eCAlELGTsNUYSSDAXL3FyzalFPe/Ln5gfHAwUw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XlzaDAitXlX0q56PRvxDgpo9f4SsvP4V6PjI5rcIR4HuMoPYdZUbc3VgSkzgGZLMkwOhagM19mTPyV6yzImhooIfSGHe7CeGNNKw/WOb7gl7uz5ob5nta5k24IG3LidPLZQVWUz0MNyJhWMJTwlXjYkpFYUCHtKTZOP2YYnpQ+Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=1bMLR4mA; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="1bMLR4mA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80F001F000FF; Sat, 12 Sep 2026 13:18:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1789219112; bh=Q99ym8STmmvZtf6mVabU4j7qQkv1FjmoiRBBdaTW4JI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=1bMLR4mAzACvSz+veOWlUJPo2N7dzcT7KZxbR7emmdea46K/BtINfEkKKFQ4Xv90P roDlQYBuv1jGozRrlfiZx08JjcKevQMbeyZIZ5qDKW0yC4iWUEKW7GteiOfiUisn4J Ml+nInV8hRIfx2ek5AuL8qa/hnEf64GBZ10o1Yic= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Hyunwoo Kim , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.12 1283/1376] Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop Date: Sat, 12 Sep 2026 09:01:49 +0200 Message-ID: <20260912065636.133402433@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260912065607.535295758@linuxfoundation.org> References: <20260912065607.535295758@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Hyunwoo Kim [ Upstream commit 44c98fd082eafd49d55a8a4077ff488175b2fe24 ] rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Hyunwoo Kim Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin --- net/bluetooth/rfcomm/core.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c index 130fe64340845..676989ff75737 100644 --- a/net/bluetooth/rfcomm/core.c +++ b/net/bluetooth/rfcomm/core.c @@ -1458,6 +1458,10 @@ static int rfcomm_apply_pn(struct rfcomm_dlc *d, int cr, struct rfcomm_pn *pn) d->mtu = __le16_to_cpu(pn->mtu); + /* MTU 0 causes an infinite loop when fragmenting in sendmsg */ + if (!d->mtu) + d->mtu = RFCOMM_DEFAULT_MTU; + if (cr && d->mtu > s->mtu) d->mtu = s->mtu; -- 2.53.0