Re: [PATCH] Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop

Hi Hyunwoo,

On Thu, Mar 19, 2026 at 11:15 AM Hyunwoo Kim <[email protected]> wrote:
>
> 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 <[email protected]>
> ---
>  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 611a9a94151e..f9b428b1f1c8 100644
> --- a/net/bluetooth/rfcomm/core.c
> +++ b/net/bluetooth/rfcomm/core.c
> @@ -1423,6 +1423,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.43.0

Looks like we never processed this one, that said I actually wonder if
pn->mtu of 0 is actually valid and perhaps we should probably
reject/disconnect.

-- 
Luiz Augusto von Dentz