fddi: validate skb length before parsing headers

fddi_type_trans() reads FDDI header fields from skb->data without first
checking that the received frame is long enough for those fields.

The destination address spans offsets 1-6 and the LLC dsap field is at
offset 13.  For SNAP frames, fddi->hdr.llc_snap.ethertype is at offsets
19-20.  A truncated 15-byte frame with dsap != 0xe0 therefore enters the
SNAP branch and reads the ethertype past the end of the frame.

KASAN reports this when such a frame is processed through a dummy FDDI
netdev that calls the real fddi_type_trans() on an exact kmalloc() copy
of the frame:

  BUG: KASAN: slab-out-of-bounds in fddi_type_trans+0x385/0x3a0
  Read of size 2 at addr ffff888009c6fe33
  The buggy address is located 4 bytes to the right of
  allocated 15-byte region [ffff888009c6fe20, ffff888009c6fe2f)

Reject short frames before reading the fields: require the minimum 802.2
header length before accessing dsap or daddr, and require the full SNAP
header length before reading the SNAP ethertype.  Returning protocol 0
causes the malformed packet to be ignored by protocol handlers.

Cc: <stable+noautosel@kernel.org> # devices should drop runt frames, repro uses a fake driver
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260607112408.92988-1-zhaoyz24@mails.tsinghua.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

0 files changed, 0 insertions, 0 deletions