On Mon, 3 Feb 2025 10:19:27 +0100
Enrique Llorente Pastora
On Sat, Feb 1, 2025 at 2:13 PM Stefano Brivio
wrote: On Fri, 31 Jan 2025 15:53:29 +0100 Enrique Llorente
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