dhcpcd.git, branch dhcpcd-7.2.2 DHCP / IPv4LL / IPv6RA / DHCPv6 client DHCPv6: Fix exclude prefix length check. 2019-05-04T09:19:02+00:00 Roy Marples roy@marples.name 2019-05-04T09:19:02+00:00 d30538898e39cc9a49ced4e67e91013d1d84a2c2 






Release dhcpcd-7.2.2
2019-05-04T08:41:16+00:00

Roy Marples
roy@marples.name

2019-05-04T08:41:16+00:00

ba146897a3c8268406a6553533f79057d21ee0b1












sun: More validation around route messages
2019-05-04T08:17:01+00:00

Roy Marples
roy@marples.name

2019-05-04T08:17:01+00:00

c4188c7a7a73f108eceda4a549d42188d77c8731












sun: Apply same RTM validation from BSD
2019-05-03T15:44:13+00:00

Roy Marples
roy@marples.name

2019-05-03T15:44:13+00:00

46af7e26355da129c6d58b214f54792e9515d0a1












BSD: Ignore coverity errors
2019-05-03T15:27:35+00:00

Roy Marples
roy@marples.name

2019-05-03T15:27:35+00:00

7c361f62838e029d4b234f7e772bf8dd5447e798

We could do ((char *)rtm) + rtm->rtm_msglen but that looks
more ugly than rtm + 1.





We could do ((char *)rtm) + rtm->rtm_msglen but that looks
more ugly than rtm + 1.







BSD: Validate RTM message lengths received
2019-05-03T14:44:51+00:00

Roy Marples
roy@marples.name

2019-05-03T14:44:51+00:00

ff89567168e3c3ea4669d4f7bb43a3400fef6c28

Doubtful these lengths would be invalid, but you never know.





Doubtful these lengths would be invalid, but you never know.







BPF: Fix ARP BPF filter to actually filter unwanted ARP message types
2019-05-03T13:50:28+00:00

Roy Marples
roy@marples.name

2019-05-03T13:50:28+00:00

cced5f563de22984fdbc38299b65ba0de128f31b

While here, clarify the BPF instruction space needed for ARP as it
could overflow in the very unlikely event we ARP for three
addresses at the same time.





While here, clarify the BPF instruction space needed for ARP as it
could overflow in the very unlikely event we ARP for three
addresses at the same time.







DHCPv6: Fix a potential read overflow with D6_OPTION_PD_EXCLUDE
2019-05-03T13:44:06+00:00

Roy Marples
roy@marples.name

2019-05-03T13:44:06+00:00

024bc211772338002f964b1f6dd223e638428665

dhcpcd only checks that the prefix length of the exclusion
matches the prefix length of the ia and equals the length of the
data in the option.
This could potentially overrun the in6_addr structure.

This is fixed by enforcing RFC 6603 section 4.2 option limits
more clearly.

Thanks to Maxime Villard <max@m00nbsd.net> for finding this.





dhcpcd only checks that the prefix length of the exclusion
matches the prefix length of the ia and equals the length of the
data in the option.
This could potentially overrun the in6_addr structure.

This is fixed by enforcing RFC 6603 section 4.2 option limits
more clearly.

Thanks to Maxime Villard <max@m00nbsd.net> for finding this.







Fix a small brain fart causing LINK_UNKNOWN to spin.
2019-05-02T20:48:52+00:00

Roy Marples
roy@marples.name

2019-05-02T20:48:52+00:00

4f6f72cd3807e0c3ebcf450007612b1c79fc143a












BSD: Simplify carrier detection once more.
2019-05-02T20:25:57+00:00

Roy Marples
roy@marples.name

2019-05-02T20:25:57+00:00

fbfa48bcfc205f3ab607ef0f9cd65e3e8948bc43

RTM_IFINFO messages now send the un-molested link status to
the main carrier handler which no longer polls on LINK_UNKNOWN.
Instead, we check carrier status directly, which if unsupported
we instead interface flags.

This is 2019, all interface drivers should report link status
correctly via RTM_IFINFO messages and trying to constantly work
around this is error prone and time consuming.





RTM_IFINFO messages now send the un-molested link status to
the main carrier handler which no longer polls on LINK_UNKNOWN.
Instead, we check carrier status directly, which if unsupported
we instead interface flags.

This is 2019, all interface drivers should report link status
correctly via RTM_IFINFO messages and trying to constantly work
around this is error prone and time consuming.