In the Linux kernel, the following vulnerability has been resolved: bpf/bonding: reject vlan+srcmac xmithashpolicy change when XDP is loaded bondoptionmodeset() already rejects mode changes that would make a loaded XDP program incompatible via bondxdpcheck(). However, bondoptionxmithashpolicyset() has no such guard. For 802.3ad and balance-xor modes, bondxdpcheck() returns false when xmithashpolicy 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 xmithashpolicy (e.g. layer2+3). 2. Change xmithashpolicy to vlan+srcmac while XDP remains loaded. This leaves bond->xdpprog set but bondxdpcheck() now returning false for the same device. When the bond is later destroyed, devxdpuninstall() calls bondxdpset(dev, NULL, NULL) to remove the program, which hits the bondxdpcheck() guard and returns -EOPNOTSUPP, triggering: WARNON(devxdpinstall(dev, mode, bpfop, NULL, 0, NULL)) Fix this by rejecting xmithashpolicy 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 bondxdpcheck() which returns false for 802.3ad/balance-xor modes when xmithashpolicy is vlan+srcmac. The check was wired into bondxdpset() to reject XDP attachment with an incompatible policy, but the symmetric path -- preventing xmithashpolicy from being changed to an incompatible value after XDP is already loaded -- was left unguarded in bondoptionxmithashpolicyset(). Note: commit 094ee6017ea0 ("bonding: check xdp prog when set bond mode") later added a similar guard to bondoptionmodeset(), but bondoptionxmithashpolicyset() remained unprotected.