-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sd-dhcp6-lease: Ignore invalid bytes at the end of the packet #28138
Conversation
Looks reasonble, but I wonder how liberal we should be:
The patch does 2., but I'm not sure what the most correct thing to do is. @yuwata comments? |
The options are TLV so for 3) I'd fear that we lose synchronization. At the end of the packet this works. The unknown option is also ignored as intended. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, if it works.
Could you provide the dumped packet (feel free to hide privacy data if you'd like) and add a test based on the packet?
Is there an existing test harness to put this in? I only saw an integration test that runs a DHCPv6 server. The packet looks like this:
|
Please update src/libsystemd-network/test-dhcp6-client.c, e.g. copy TEST(client_parse_message_issue_24002) and modify the packet binary based on what you paste. |
Oracle Cloud sends malformed DHCPv6 replies that have an invalid byte at the end, which cannot be parsed as an option code. networkd currently can cope with the invalid option (it is ignored), but the whole packet is ignored altogether because of the additional null at the end. It's better to be liberal in what we accept and actually assign an address, given that the reply contains a valid IA_NA. Fixes systemd#28183.
Added a brief test about that, and worked fine for me. Setting the green label. |
Oracle Cloud sends malformed DHCPv6 replies that end in a DHCP option 0 containing a NoPrefixAvail status message (and thus should probably be an IA_PD) option and an additional null byte that does not parse as an option code.
networkd currently can cope with the invalid option (it is ignored), but the whole packet is ignored altogether because of the additional null at the end.
It's better to be liberal in what we accept and actually assign an address, given that the reply contains a valid IA_NA.
(Technically this is a glorified
if 1 < 2
check. But it's checking for the condition that will yield-EBADMSG
fromdhcp6_option_parse
.)