Re: [PATCH net 1/2] bonding: reject frames with insufficient headroom in bond_header_create

Hi Hangbin,

Thanks for the catch. You're right, my wording was inaccurate. This is not
about an active slave switch or changing the bond type while sending.

The issue is a hard_header_len update race in bond_setup_by_slave(). An
in-flight AF_PACKET SOCK_DGRAM send can snapshot the old
bond_dev->hard_header_len
for skb headroom reservation, then bond_setup_by_slave() updates it and
installs a new active slave. The existing send path can continue after this
because dev_close()/dev_open() does not synchronize with already running
packet_snd().

Later bond_header_create() uses the new active slave's hard_header_len, which
may be larger than the reserved headroom.

For the first-slave case, the bond can be slaveless before enslaving, so
removing existing slaves does not prevent this window.

Thanks,
Qihang

On Thu, Aug 27, 2026 at 9:10 AM Hangbin Liu [off-list ref] wrote:

Hi Qinghang,

On Mon, Aug 24, 2026 at 10:18:01AM +0800, Qihang wrote:

quoted

From: Qihang Tang <redacted>

AF_PACKET SOCK_DGRAM sends reserve skb headroom from a snapshot of
bond_dev->hard_header_len.  A concurrent bond type change can switch the
active slave to one with a larger hard_header_len between that snapshot
and bond_header_create(), so the slave's create() pushes or writes past
skb->head.

How can bonding change its device type while still sending skbs?
Bonding does not allow enslaving devices of different types. We have
to remove all slaves before changing its type.

Thanks
Hangbin