Re: [PATCH v4 net 1/2] net: vlan: always set hard_header_len with VLAN_HLEN

[Paolo Abeni <pabeni@redhat.com>]

On 1/26/26 5:04 AM, Chen Zhen wrote:
> When tx-vlan-hw-insert is toggled to on, vlan device hard_header_len
> will be reduced to dev->hard_header_len since commit 029f5fc31cdb
> ("8021q: set hard_header_len when VLAN offload features are toggled"),
> but the header_ops remains unchanged, ndisc skb will be allocated
> with this len and filled in vlan hdr in vlan_dev_hard_header(), but
> with reorder_hdr off, the skb room is not enough so it triggers
> skb_panic() as below:
> 
> skbuff: skb_under_panic: text:ffffffffa0535126 len:90 put:14
>  head:ffff916c04232ec0 data:ffff916c04232ebe tail:0x58 end:0x180 dev:veth0.10
> ------------[ cut here ]------------
>  kernel BUG at net/core/skbuff.c:197!
>  <TASK>
>   skb_push+0x39/0x40 net/core/skbuff.c:207
>   eth_header+0x26/0xb0 net/ethernet/eth.c:90
>   vlan_dev_hard_header+0x58/0x130 net/8021q/vlan_dev.c:85 [8021q]
>   neigh_connected_output+0xae/0x100 net/core/neighbour.c:1589
>   ip6_finish_output2+0x2cc/0x650 net/ipv6/ip6_output.c:213
>   ip6_finish_output+0x27/0xd0 net/ipv6/ip6_output.c:246
>   ndisc_send_skb+0x1d0/0x370 net/ipv6/ndisc.c:516
>   ndisc_send_ns+0x5a/0xb0 net/ipv6/ndisc.c:672
>   addrconf_dad_work+0x2b5/0x380 net/ipv6/addrconf.c:4258
>   process_one_work+0x17f/0x320 kernel/workqueue.c:2743
> 
> In case of possible crash from other callers, fix this by always
> reserving VLAN_HLEN in hard_header_len even if the header_ops would
> not request it.
> 
> Fixes: 029f5fc31cdb ("8021q: set hard_header_len when VLAN offload features are toggled")
> Signed-off-by: Chen Zhen <chenzhen126@huawei.com>
> ---
>  net/8021q/vlan.c     | 5 -----
>  net/8021q/vlan_dev.c | 8 +++-----
>  2 files changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
> index 2b74ed56eb16..a7b5da7f9999 100644
> --- a/net/8021q/vlan.c
> +++ b/net/8021q/vlan.c
> @@ -323,11 +323,6 @@ static void vlan_transfer_features(struct net_device *dev,
>  
>  	netif_inherit_tso_max(vlandev, dev);
>  
> -	if (vlan_hw_offload_capable(dev->features, vlan->vlan_proto))
> -		vlandev->hard_header_len = dev->hard_header_len;
> -	else
> -		vlandev->hard_header_len = dev->hard_header_len + VLAN_HLEN;
> -
>  #if IS_ENABLED(CONFIG_FCOE)
>  	vlandev->fcoe_ddp_xid = dev->fcoe_ddp_xid;
>  #endif
> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
> index fbf296137b09..9e81669bffd6 100644
> --- a/net/8021q/vlan_dev.c
> +++ b/net/8021q/vlan_dev.c
> @@ -572,13 +572,11 @@ static int vlan_dev_init(struct net_device *dev)
>  #endif
>  
>  	dev->needed_headroom = real_dev->needed_headroom;
> -	if (vlan_hw_offload_capable(real_dev->features, vlan->vlan_proto)) {
> +	dev->hard_header_len = real_dev->hard_header_len + VLAN_HLEN;

I'm wondering if the above would foul hard_header_len users to do
wrong/bad mac comparison, i.e. in gro_list_prepare()  ?

/P