On 7/1/19 11:01 AM, Matteo Croce wrote:
> Avoid the situation where an IPV6 only flag is applied to an IPv4 address:
>
> # ip addr add 192.0.2.1/24 dev dummy0 nodad home mngtmpaddr noprefixroute
> # ip -4 addr show dev dummy0
> 2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state
> UNKNOWN group default qlen 1000
> inet 192.0.2.1/24 scope global noprefixroute dummy0
> valid_lft forever preferred_lft forever
>
> Or worse, by sending a malicious netlink command:
>
> # ip -4 addr show dev dummy0
> 2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state
> UNKNOWN group default qlen 1000
> inet 192.0.2.1/24 scope global nodad optimistic dadfailed home
> tentative mngtmpaddr noprefixroute stable-privacy dummy0
> valid_lft forever preferred_lft forever
>
> Signed-off-by: Matteo Croce <mcr...@redhat.com>
> ---
> net/ipv4/devinet.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index c6bd0f7a020a..c5ebfa199794 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@ -62,6 +62,11 @@
> #include <net/net_namespace.h>
> #include <net/addrconf.h>
>
> +#define IPV6ONLY_FLAGS \
> + (IFA_F_NODAD | IFA_F_OPTIMISTIC | IFA_F_DADFAILED | \
> + IFA_F_HOMEADDRESS | IFA_F_TENTATIVE | \
> + IFA_F_MANAGETEMPADDR | IFA_F_STABLE_PRIVACY)
> +
> static struct ipv4_devconf ipv4_devconf = {
> .data = {
> [IPV4_DEVCONF_ACCEPT_REDIRECTS - 1] = 1,
> @@ -468,6 +473,9 @@ static int __inet_insert_ifa(struct in_ifaddr *ifa,
> struct nlmsghdr *nlh,
> ifa->ifa_flags &= ~IFA_F_SECONDARY;
> last_primary = &in_dev->ifa_list;
>
> + /* Don't set IPv6 only flags to IPv4 addresses */
> + ifa->ifa_flags &= ~IPV6ONLY_FLAGS;
> +
> for (ifap = &in_dev->ifa_list; (ifa1 = *ifap) != NULL;
> ifap = &ifa1->ifa_next) {
> if (!(ifa1->ifa_flags & IFA_F_SECONDARY) &&
>
I guess at this point we can fail the address add, so this is the best
option. rtm_to_ifaddr could set a message in extack about invalid flags
- not fail the change, just warn the user that flags will be ignored.
Reviewed-by: David Ahern <dsah...@gmail.com>
