CVE-2026-23310

In the Linux kernel, the following vulnerability has been resolved:

bpf/bonding: reject vlan+srcmac xmit_hash_policy change when XDP is loaded

bond_option_mode_set() already rejects mode changes that would make a

loaded XDP program incompatible via bond_xdp_check(). However,

bond_option_xmit_hash_policy_set() has no such guard.

For 802.3ad and balance-xor modes, bond_xdp_check() returns false when

xmit_hash_policy is vlan+srcmac, because the 802.1q payload is usually

absent due to hardware offload. This means a user can:

1. Attach a native XDP program to a bond in 802.3ad/balance-xor mode

with a compatible xmit_hash_policy (e.g. layer2+3).

2. Change xmit_hash_policy to vlan+srcmac while XDP remains loaded.

This leaves bond->xdp_prog set but bond_xdp_check() now returning false

for the same device. When the bond is later destroyed, dev_xdp_uninstall()

calls bond_xdp_set(dev, NULL, NULL) to remove the program, which hits

the bond_xdp_check() guard and returns -EOPNOTSUPP, triggering:

WARN_ON(dev_xdp_install(dev, mode, bpf_op, NULL, 0, NULL))

Fix this by rejecting xmit_hash_policy changes to vlan+srcmac when an

XDP program is loaded on a bond in 802.3ad or balance-xor mode.

commit 39a0876d595b ("net, bonding: Disallow vlan+srcmac with XDP")

introduced bond_xdp_check() which returns false for 802.3ad/balance-xor

modes when xmit_hash_policy is vlan+srcmac. The check was wired into

bond_xdp_set() to reject XDP attachment with an incompatible policy, but

the symmetric path -- preventing xmit_hash_policy from being changed to an

incompatible value after XDP is already loaded -- was left unguarded in

bond_option_xmit_hash_policy_set().

Note:

commit 094ee6017ea0 ("bonding: check xdp prog when set bond mode")

later added a similar guard to bond_option_mode_set(), but

bond_option_xmit_hash_policy_set() remained unprotected.