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

dhcp6 packet size calculation fixes #10518

merged 5 commits into from Oct 25, 2018


3 participants

poettering commented Oct 25, 2018

No description provided.

poettering added some commits Oct 19, 2018

dhcp6: make sure we have enough space for the DHCP6 option header
Fixes a vulnerability originally discovered by Felix Wilhelm from

LP: #1795921
dhcp6: prefer offsetof() over sizeof() for structs with undefined sizes
This doesn't change anything in the generated source, but I think makes
semantically more sense, as these structures have undefined size, and we
only want to know the size up to the data field in these cases.

@poettering poettering merged commit 5ec1fca into systemd:master Oct 25, 2018

5 of 8 checks passed

bionic-amd64 autopkgtest running
bionic-arm64 autopkgtest running
bionic-i386 autopkgtest running
Fedora Rawhide CI x86_64 rpm build [succeeded]
LGTM analysis: C/C++ No alert changes
LGTM analysis: JavaScript No code changes detected
bionic-s390x autopkgtest finished (success)
semaphoreci The build passed on Semaphore.
@@ -106,7 +106,7 @@ int dhcp6_option_append_ia(uint8_t **buf, size_t *buflen, const DHCP6IA *ia) {
return -EINVAL;
if (*buflen < len)
if (*buflen < offsetof(DHCP6Option, data) + len)

This comment has been minimized.


evverx Oct 26, 2018


So it seems that it's not uncommon for dhcp6-client to get the length wrong. The receiving side is more or less covered by the dhcp6-client fuzzer (which has helped to find three similar issues this month). Maybe it would make sense to somehow cover the sending side too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment