linux-kernel - Re: [PATCH net-next v2 4/6] vxlan: check valid combinations of address scopes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dcf7f3b9-09ff-4072-9dd6-3dc33932cac1@universe-factory.net>
Date:   Sun, 16 Apr 2017 16:57:44 +0200
From:   Matthias Schiffer <mschiffer@...verse-factory.net>
To:     Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
Cc:     davem@...emloft.net, jbenc@...hat.com, hannes@...essinduktion.org,
        pshelar@....org, aduyck@...antis.com, roopa@...ulusnetworks.com,
        netdev@...r.kernel.org, dev@...nvswitch.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2 4/6] vxlan: check valid combinations of
 address scopes

On 04/14/2017 07:27 PM, Sergei Shtylyov wrote:
> On 04/14/2017 07:44 PM, Matthias Schiffer wrote:
> 
>> * Multicast addresses are never valid as local address
>> * Link-local IPv6 unicast addresses may only be used as remote when the
>>   local address is link-local as well
>> * Don't allow link-local IPv6 local/remote addresses without interface
>>
>> We also store in the flags field if link-local addresses are used for the
>> follow-up patches that actually make VXLAN over link-local IPv6 work.
>>
>> Signed-off-by: Matthias Schiffer <mschiffer@...verse-factory.net>
>> ---
>>
>> v2: was "vxlan: don't allow link-local IPv6 local/remote addresses without
>> interface" before. v2 does a lot more checks and adds the
>> VXLAN_F_IPV6_LINKLOCAL flag.
>>
>>  drivers/net/vxlan.c | 35 +++++++++++++++++++++++++++++++++++
>>  include/net/vxlan.h |  2 ++
>>  2 files changed, 37 insertions(+)
>>
>> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
>> index 07f89b037681..95a71546e8f2 100644
>> --- a/drivers/net/vxlan.c
>> +++ b/drivers/net/vxlan.c
>> @@ -2881,11 +2881,39 @@ static int vxlan_config_validate(struct net
>> *src_net, struct vxlan_config *conf,
>>      if (conf->saddr.sa.sa_family != conf->remote_ip.sa.sa_family)
>>          return -EINVAL;
>>
>> +    if (vxlan_addr_multicast(&conf->saddr))
>> +        return -EINVAL;
>> +
>>      if (conf->saddr.sa.sa_family == AF_INET6) {
>>          if (!IS_ENABLED(CONFIG_IPV6))
>>              return -EPFNOSUPPORT;
>>          use_ipv6 = true;
>>          conf->flags |= VXLAN_F_IPV6;
>> +
>> +        if (!(conf->flags & VXLAN_F_COLLECT_METADATA)) {
>> +            int local_type =
>> +                ipv6_addr_type(&conf->saddr.sin6.sin6_addr);
>> +            int remote_type =
>> +                ipv6_addr_type(&conf->remote_ip.sin6.sin6_addr);
>> +
>> +            if (local_type & IPV6_ADDR_LINKLOCAL) {
>> +                if (!(remote_type & IPV6_ADDR_LINKLOCAL) &&
>> +                    (remote_type != IPV6_ADDR_ANY)) {
>> +                    pr_info("invalid combination of address scopes\n");
> 
>    Maybe pr_err()?

Hmm, I mostly followed the style of the existing code, which uses pr_info
for such messages. Also, these messages can be triggered by userspace, as
they're diagnostics for the newlink/changelink operations; I'm not
convinced that their importance justifies pr_err().

Generally, it seems unusual to me to use the kernel log for configuration
diagnostics at all; just removing the messages would be another option.
Stephen also mentioned "extended netlink error reporting", but I guess that
can be done in another patchset.

Matthias



Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)