netdev - tc flower IP address keys

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-next>] [day] [month] [year] [list]

Message-ID: <3a84e589-9e99-5f6e-cfd6-35eb04a4a428@solarflare.com>
Date:   Thu, 10 Jan 2019 13:42:49 +0000
From:   Edward Cree <ecree@...arflare.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>, netdev <netdev@...r.kernel.org>
Subject: tc flower IP address keys

I think there is a bug in net/sched/cls_flower.c:fl_init_dissector(),
 where it reads

    FL_KEY_SET_IF_MASKED(mask, keys, cnt,
                 FLOW_DISSECTOR_KEY_IPV4_ADDRS, ipv4);
    FL_KEY_SET_IF_MASKED(mask, keys, cnt,
                 FLOW_DISSECTOR_KEY_IPV6_ADDRS, ipv6);

(and correspondingly further down for enc IP addrs), in that fl_flow_key
 stores ipv4 and ipv6 in a union, meaning that if a tc flower filter sets,
 for instance, a destination IPv4 address (and an ethertype of IPv4), the
 mask for this will also show up in the middle of the source ipv6 address,
 and lead to the ipv6 key being marked as used.  Thus subsequently a call
 to dissector_uses_key(..., FLOW_DISSECTOR_KEY_IPV6_ADDRS) will return
 true.
While this can be disambiguated by examining key->control.addr_type, this
 seems like it ought not to be necessary.  I apologise if this has been
 asked before, but is there a reason why the core code cannot fix this up
 and prevent drivers from seeing it in their tc offload routines?

-Ed