[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b906bf83-a2b3-45fa-b3fc-1a9242b783a0@redhat.com>
Date: Thu, 29 Jan 2026 12:08:04 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Chen Zhen <chenzhen126@...wei.com>, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, horms@...nel.org
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
huyizhen2@...wei.com, gaoxingwang1@...wei.com
Subject: Re: [PATCH v4 net 1/2] net: vlan: always set hard_header_len with
VLAN_HLEN
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@...wei.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
Powered by blists - more mailing lists