Re: [PATCH net v1] bonding: fix type confusion in bond_setup_by_slave()
From: Eric Dumazet
Date: Wed Mar 04 2026 - 02:10:25 EST
On Sat, Feb 28, 2026 at 10:59 AM Jiayuan Chen <jiayuan.chen@xxxxxxxxx> wrote:
>
> From: Jiayuan Chen <jiayuan.chen@xxxxxxxxxx>
>
>
> When a device (e.g. GRE tunnel) is enslaved to a bond,
> bond_setup_by_slave() directly copies the slave's header_ops to the
> bond device:
>
> bond_dev->header_ops = slave_dev->header_ops;
>
> This causes a type confusion when dev_hard_header() is later called
> on the bond device. Functions like ipgre_header(), ip6gre_header(),
> vlan_dev_hard_header(), and macvlan_hard_header() all use
> netdev_priv(dev) to access their device-specific private data. When
> called with the bond device, netdev_priv() returns the bond's private
> data (struct bonding) instead of the expected type (e.g. struct
> ip_tunnel), leading to garbage values being read and kernel crashes.
>
> Fix this by introducing bond_header_ops with wrapper functions that
> delegate to the active slave's header_ops using the slave's own
> device. This ensures netdev_priv() in the slave's header functions
> always receives the correct device.
>
> The fix is placed in the bonding driver rather than individual device
> drivers, as the root cause is bond blindly inheriting header_ops from
> the slave without considering that these callbacks expect a specific
> netdev_priv() layout.
>
> The type confusion can be observed by adding a printk in
> ipgre_header() and running the following commands:
>
> ip link add dummy0 type dummy
> ip addr add 10.0.0.1/24 dev dummy0
> ip link set dummy0 up
> ip link add gre1 type gre local 10.0.0.1
> ip link add bond1 type bond mode active-backup
> ip link set gre1 master bond1
> ip link set gre1 up
> ip link set bond1 up
> ip addr add fe80::1/64 dev bond1
>
> Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
> Signed-off-by: Jiayuan Chen <jiayuan.chen@xxxxxxxxxx>
> ---
Reviewed-by: Eric Dumazet <edumazet@xxxxxxxxxx>