netdev - Re: [PATCH net-next] ipvlan: implemente .parse_protocol hook function in ipvlan_header

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: <6568cddb64f2c_f7062294da@willemb.c.googlers.com.notmuch>
Date: Thu, 30 Nov 2023 13:00:59 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Zhengchao Shao <shaozhengchao@...wei.com>, 
 netdev@...r.kernel.org, 
 davem@...emloft.net, 
 edumazet@...gle.com, 
 kuba@...nel.org, 
 pabeni@...hat.com
Cc: fw@...len.de, 
 luwei32@...wei.com, 
 shaozhengchao@...wei.com, 
 weiyongjun1@...wei.com, 
 yuehaibing@...wei.com, 
 maheshb@...gle.com
Subject: Re: [PATCH net-next] ipvlan: implemente .parse_protocol hook function
 in ipvlan_header_ops

Zhengchao Shao wrote:
> The .parse_protocol hook function in the ipvlan_header_ops structure is
> not implemented. As a result, when the AF_PACKET family is used to send
> packets, skb->protocol will be set to 0.
> The IPVLAN device must be of the Ethernet type. Therefore, use
> eth_header_parse_protocol function to obtain the protocol.
> 
> Signed-off-by: Zhengchao Shao <shaozhengchao@...wei.com>

Reviewed-by: Willem de Bruijn <willemb@...gle.com>

Small typo in the subject line: implemente.

Ipvlan is a device of type ARPHRD_ETHER (ether_setup).

Tangential to this patch:

I checked that ipvlan_start_xmit indeed only expects packets with
skb->data at Ethernet header. ipvlan_queue_xmit checks

        if (unlikely(!pskb_may_pull(skb, sizeof(struct ethhdr))))
                goto out;

It may later call ipvlan_xmit_mode_l3 and ipvlan_get_L3_hdr, which
has such cases:

        case htons(ETH_P_IP): {
                u32 pktlen;
                struct iphdr *ip4h;
            
                if (unlikely(!pskb_may_pull(skb, sizeof(*ip4h))))
                        return NULL;

That pskb_may_pull should include the ethernet header. It gets
pulled for L3 mode in ipvlan_process_outbound, *after* the above.

> ---
>  drivers/net/ipvlan/ipvlan_main.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
> index 57c79f5f2991..f28fd7b6b708 100644
> --- a/drivers/net/ipvlan/ipvlan_main.c
> +++ b/drivers/net/ipvlan/ipvlan_main.c
> @@ -387,6 +387,7 @@ static const struct header_ops ipvlan_header_ops = {
>  	.parse		= eth_header_parse,
>  	.cache		= eth_header_cache,
>  	.cache_update	= eth_header_cache_update,
> +	.parse_protocol	= eth_header_parse_protocol,
>  };
>  
>  static void ipvlan_adjust_mtu(struct ipvl_dev *ipvlan, struct net_device *dev)
> -- 
> 2.34.1
>