Re: [PATCH] dhcp: Don't re-use request message for reply

[Stefano Brivio <sbrivio@redhat.com>]

On Mon, 3 Feb 2025 10:19:27 +0100
Enrique Llorente Pastora <ellorent@redhat.com> wrote:

> On Sat, Feb 1, 2025 at 2:13 PM Stefano Brivio <sbrivio@redhat.com> wrote:
> >
> > On Fri, 31 Jan 2025 15:53:29 +0100
> > Enrique Llorente <ellorent@redhat.com> wrote:
> >  
> > > The logic composing the DHCP reply message is reusing the request
> > > message to compose the it, this kind be problematic from a security  
> >
> > Does "be problematic" imply "would be ... once we add longer options"?
> >  
> > > context and may break the functionality.  
> >
> > Which one? This is important to know for distribution maintainers and,
> > ultimately, users.
> >
> > As far as I know it's all fine until now, the problem would arise in
> > your next patch, so perhaps state that.
> >
> > The real reason why we need this is that we want to have a given, fixed
> > size for the option field (308) so that we can easily check we don't
> > exceed it once we start writing the FQDN in it.
> >  
> > > This change create a new reply message and fill it in with proper fields
> > > from request adding on top the generated opetions.  
> >
> > s/opetions/options/
> 
> Thinking about it twice, maybe we don't need this change after all,
> from what I see at
> code it override the request options with the reply options and then
> add the 255 finalizer and some padding if
> is less than 308, meaning that the request options has no effect on
> reply, isn't that enough ?

It's not, because with FQDN options we can easily exceed the minimum
size of a DHCP message we get, so the original message might not be
enough to write everything we need to write.

It's about the lower bound (of the size), not the upper bound.

-- 
Stefano