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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox