Re: [PATCH] Bluetooth: BNEP: validate control header bytes before reading them

[Pengpeng Hou]

Hi Paul,

Thanks for the review.

The Date/Received mismatch is on me. I resent from a locally generated
patch file and preserved its original Date header, so the SMTP receive
time ended up being newer than the message Date. I will correct that on
the next resend.

I do not have a polished userspace reproducer prepared yet, but the bug
can be triggered with short malformed BNEP payloads passed to
bnep_rx_frame().

The minimal cases are:

  1. 0x01  (or 0x81)

     This is a 1-byte BNEP_CONTROL frame. After the initial skb_pull(skb, 1),
     skb->len becomes 0, but the current code still does

         ctrl_type = *(u8 *)skb->data;

  2. 0x81 0x01

     This is BNEP_CONTROL | BNEP_EXT_HEADER with ctrl_type
     BNEP_SETUP_CONN_REQ. Later, in the control-message pull path,
     the code reads

         *(u8 *)(skb->data + 1)

     for the length byte, even though only the ctrl byte is present.

  3. 0x81 0x03   or   0x81 0x05

     These are BNEP_FILTER_NET_TYPE_SET / BNEP_FILTER_MULTI_ADDR_SET.
     Later the code reads

         *(u16 *)(skb->data + 1)

     for the 16-bit length field, even though that field is absent.

So the issue is reproducible with truncated control skb payloads before
any valid length byte / 16-bit length field is available.

If useful, I can also turn one of the above cases into a small standalone
reproducer for the receive path.

Thanks,
Pengpeng