netdev - Re: [PATCH net-next v3 1/4] net: sched: em_ipt: match only on ip/ipv6 traffic

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: <77B4535F-0086-447B-B77A-F8D2348DC1AC@cumulusnetworks.com>
Date:   Thu, 27 Jun 2019 19:13:49 +0300
From:   nikolay@...ulusnetworks.com
To:     Eyal Birger <eyal.birger@...il.com>
CC:     netdev@...r.kernel.org, roopa@...ulusnetworks.com,
        davem@...emloft.net, pablo@...filter.org, xiyou.wangcong@...il.com,
        jiri@...nulli.us, jhs@...atatu.com
Subject: Re: [PATCH net-next v3 1/4] net: sched: em_ipt: match only on ip/ipv6 traffic

On 27 June 2019 19:02:37 EEST, Eyal Birger <eyal.birger@...il.com> wrote:
>Hi Nik,
>
>On Thu, 27 Jun 2019 11:10:44 +0300
>Nikolay Aleksandrov <nikolay@...ulusnetworks.com> wrote:
>
>> Restrict matching only to ip/ipv6 traffic and make sure we can use
>the
>> headers, otherwise matches will be attempted on any protocol which
>can
>> be unexpected by the xt matches. Currently policy supports only
>> ipv4/6.
>> 
>> Signed-off-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
>> ---
>> v3: no change
>> v2: no change
>> 
>>  net/sched/em_ipt.c | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>> 
>> diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
>> index 243fd22f2248..64dbafe4e94c 100644
>> --- a/net/sched/em_ipt.c
>> +++ b/net/sched/em_ipt.c
>> @@ -185,6 +185,19 @@ static int em_ipt_match(struct sk_buff *skb,
>> struct tcf_ematch *em, struct nf_hook_state state;
>>  	int ret;
>>  
>> +	switch (tc_skb_protocol(skb)) {
>> +	case htons(ETH_P_IP):
>> +		if (!pskb_network_may_pull(skb, sizeof(struct
>> iphdr)))
>> +			return 0;
>> +		break;
>> +	case htons(ETH_P_IPV6):
>> +		if (!pskb_network_may_pull(skb, sizeof(struct
>> ipv6hdr)))
>> +			return 0;
>> +		break;
>> +	default:
>> +		return 0;
>> +	}
>> +
>
>I just realized that I didn't consider the egress direction in my
>review.
>Don't we need an skb_pull() in that direction to make the skb->data
>point
>to L3? I see this is done e.g. in em_ipset.
>
>Eyal.

Hi Eyal,
Not for addrtype, it doesn't have such expectations.
I also tested it, everything matches properly.

Cheers,
  Nik