From: Ido Schimmel <idosch@nvidia.com>
To: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Cc: netdev@vger.kernel.org, David Ahern <dsahern@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
linux-kernel@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>,
stable@vger.kernel.org
Subject: Re: [PATCH net] ipconfig: bound BOOTP options by UDP datagram length
Date: Sun, 19 Jul 2026 11:41:42 +0300 [thread overview]
Message-ID: <20260719084142.GA1906127@shredder> (raw)
In-Reply-To: <20260713141107.10418-1-zhaoyz24@mails.tsinghua.edu.cn>
On Mon, Jul 13, 2026 at 10:11:06PM +0800, Yizhou Zhao wrote:
> ic_bootp_recv() accepts an IP packet whose total length exceeds its UDP
> datagram length. This is valid at the IP layer, but DHCP/BOOTP options
> belong to the UDP payload. The option parser nevertheless uses the IP
> total length as its end boundary.
>
> Consequently, an on-link attacker that can race a boot-time DHCP exchange
> can put DHCP options after the declared UDP payload and have ipconfig
> consume them. A QEMU/KVM reproduction with ip=dhcp accepted a forged
> DHCPOFFER/DHCPACK with an IP total length of 290 and UDP length of 248;
> the tail supplied a netmask and an off-link gateway, causing boot-time
> network configuration to fail.
>
> Use the UDP datagram end as the parser boundary. The receiver already
> verifies that the UDP datagram lies within the IP packet, so this retains
> normal valid DHCP/BOOTP parsing while excluding the IP-only tail.
>
> 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: Claude-Code:GLM-5.2-special
> Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
The code change looks correct, but why frame it as a security fix?
Can't an "on-link attacker" forge the UDP payload instead?
prev parent reply other threads:[~2026-07-19 8:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 14:11 [PATCH net] ipconfig: bound BOOTP options by UDP datagram length Yizhou Zhao
2026-07-19 8:41 ` Ido Schimmel [this message]
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=20260719084142.GA1906127@shredder \
--to=idosch@nvidia.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=fengxw06@126.com \
--cc=horms@kernel.org \
--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.