From: Simon Horman <horms@kernel.org>
To: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>,
Ao Wang <wangao@seu.edu.cn>, Xuewei Feng <fengxw06@126.com>,
Qi Li <qli01@tsinghua.edu.cn>, Ke Xu <xuke@tsinghua.edu.cn>
Subject: Re: [PATCH net] fddi: validate skb length before parsing headers
Date: Wed, 10 Jun 2026 15:24:14 +0100 [thread overview]
Message-ID: <20260610142414.GM3920875@horms.kernel.org> (raw)
In-Reply-To: <20260607112408.92988-1-zhaoyz24@mails.tsinghua.edu.cn>
On Sun, Jun 07, 2026 at 07:24:04PM +0800, Yizhou Zhao wrote:
> 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.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> 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>
> Assisted-by: GLM:GLM-5.1
> Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
I believe that drivers ensure that in practice packets hitting this path
are linear, so checking skb->len is sufficient to protect against OOB
reads.
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2026-06-10 14:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-07 11:24 [PATCH net] fddi: validate skb length before parsing headers Yizhou Zhao
2026-06-10 14:24 ` Simon Horman [this message]
2026-06-10 15:14 ` Jakub Kicinski
2026-06-10 15:20 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260610142414.GM3920875@horms.kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fengxw06@126.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=qli01@tsinghua.edu.cn \
--cc=stable@vger.kernel.org \
--cc=wangao@seu.edu.cn \
--cc=xuke@tsinghua.edu.cn \
--cc=yangyx22@mails.tsinghua.edu.cn \
--cc=zhaoyz24@mails.tsinghua.edu.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.