mirrors/linux
2
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2026-08-31 14:04:27 -04:00
Code Issues Packages Projects Releases Wiki Activity

Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop

Browse Source 
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: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This commit is contained in:
Hyunwoo Kim
2026-03-20 00:14:58 +09:00
committed by Luiz Augusto von Dentz
parent 560bef609f
commit 44c98fd082
1 changed files with 4 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
net/bluetooth/rfcomm/core.c
View File

@@ -1455,6 +1455,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;