netdev - Re: [PATCH net-next 3/5] ipv4: support sport, dport and ip protocol in RTM

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

Message-ID: <CAJieiUj-Bg8SPN3-Zm2dgNCWku=f-G_sadfkow5ZsND=GQQgXQ@mail.gmail.com>
Date:   Tue, 17 Apr 2018 19:41:55 -0700
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        David Ahern <dsa@...ulusnetworks.com>
Subject: Re: [PATCH net-next 3/5] ipv4: support sport, dport and ip protocol
 in RTM_GETROUTE

On Tue, Apr 17, 2018 at 1:10 AM, Ido Schimmel <idosch@...sch.org> wrote:
> On Mon, Apr 16, 2018 at 01:41:36PM -0700, Roopa Prabhu wrote:
>> @@ -2757,6 +2796,12 @@ static int inet_rtm_getroute(struct sk_buff *in_skb, struct nlmsghdr *nlh,
>>       fl4.flowi4_oif = tb[RTA_OIF] ? nla_get_u32(tb[RTA_OIF]) : 0;
>>       fl4.flowi4_mark = mark;
>>       fl4.flowi4_uid = uid;
>> +     if (sport)
>> +             fl4.fl4_sport = sport;
>> +     if (dport)
>> +             fl4.fl4_dport = dport;
>> +     if (ip_proto)
>> +             fl4.flowi4_proto = ip_proto;
>
> Hi Roopa,
>
> This info isn't set in the synthesized skb, but only in the flow info
> and therefore not used for input routes. I see you added a test case,
> but it's only for output routes. I believe an input route test case will
> fail.

yep. I made a note for myself to work thru the input case and missed before
i sent the series.

>
> Also, note that the skb as synthesized now is invalid - iph->ihl is 0
> for example - so the flow dissector will spit it out. It effectively
> means that route get is broken when L4 hashing is used. It also affects
> output routes because since commit 3765d35ed8b9 ("net: ipv4: Convert
> inet_rtm_getroute to rcu versions of route lookup") the skb is used to
> calculate the multipath hash.

yep, remember that. will look. thanks Ido.