CVE-2026-23310

Description

In the Linux kernel, the following vulnerability has been resolved:bpf/bonding: reject vlan+srcmac xmit_hash_policy change when XDP is loadedbond_option_mode_set() already rejects mode changes that would make aloaded 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 whenxmit_hash_policy is vlan+srcmac, because the 802.1q payload is usuallyabsent 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 falsefor the same device. When the bond is later destroyed, dev_xdp_uninstall()calls bond_xdp_set(dev, null, null) to remove the program, which hitsthe 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 anXDP 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-xormodes when xmit_hash_policy is vlan+srcmac. The check was wired intobond_xdp_set() to reject XDP attachment with an incompatible policy, butthe symmetric path -- preventing xmit_hash_policy from being changed to anincompatible value after XDP is already loaded -- was left unguarded inbond_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(), butbond_option_xmit_hash_policy_set() remained unprotected.

Risk Information

Associated Vulnerability

Patch Details

References

https://nvd.nist.gov/vuln/detail/CVE-2023-1234
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-1234