Re: [PATCH v2] Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame()

[patchwork-bot+bluetooth@kernel.org]

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Sat, 19 Sep 2026 11:25:14 +0000 you wrote:
> While rfcomm_recv_frame() verifies that skb->len is at least
> sizeof(*hdr) + 1 (4 bytes: 3-byte header + 1-byte FCS), an RFCOMM frame
> with an extended 2-byte length field (!__test_ea(hdr->len)) has a 4-byte
> header plus a 1-byte FCS (5 bytes minimum, sizeof(*hdr) + 2).
> 
> When a 4-byte RFCOMM frame with EA == 0 arrives:
> 1. The initial skb->len < sizeof(*hdr) + 1 check passes (4 < 4 is false).
> 2. Trimming the FCS byte decrements skb->len to 3.
> 3. If __check_fcs() succeeds, skb_pull(skb, 4) fails (4 > 3) and returns
>    NULL without advancing skb->data.
> 4. Because the return value of skb_pull() is ignored, the un-pulled
>    3-byte struct rfcomm_hdr remains at skb->data and is either queued as
>    application payload via rfcomm_recv_data() or parsed as a multiplexer
>    control command via rfcomm_recv_mcc() on DLCI 0.
> 
> [...]

Here is the summary with links:
  - [v2] Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame()
    https://git.kernel.org/bluetooth/bluetooth-next/c/6d91041bb38b

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html