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: <20190627190237.0a08a4a2@jimi>
Date:   Thu, 27 Jun 2019 19:02:37 +0300
From:   Eyal Birger <eyal.birger@...il.com>
To:     Nikolay Aleksandrov <nikolay@...ulusnetworks.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

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.