CVE-2023-52574

What it actually does

Null pointer dereference in vlan_dev_hard_header when a VLAN device is enslaved to a team netdevice whose type changes from non-ether to ether, incorrectly assigning vlan_header_ops and dereferencing a non-existent real_dev pointer.

Why it matters to the business

Local users can trigger kernel crashes on Linux systems using team networking with VLAN devices, causing denial of service and potential loss of availability on servers or appliances.

How an attack unfolds

An attacker with local access runs teamd to create a loadbalance team, adds dummy and VLAN interfaces, enslaves an nlmon device, then toggles the team type and VLAN master assignment to force the header_ops swap that triggers the NULL dereference.

How to fix it

Upgrade the Linux kernel to a version containing commit 1779eb51b9cc628cee551f252701a85a2a50a457 or apply the equivalent stable backport that caches eth_header_ops in team_setup and restores it on type change.

How to confirm the fix worked

Verify the presence of commit 1779eb51b9cc628cee551f252701a85a2a50a457 in the kernel source or confirm the running kernel is newer than the vulnerable tagged releases; test the original reproducer sequence to ensure no crash occurs.

Typical attack path

1. Create team0 with loadbalance runner via teamd
2. Add dummy interface and VLAN sub-interface
3. Add nlmon interface and temporarily enslave it to team0
4. Bring interfaces up and change team type from non-ether to ether while enslaving the VLAN device
5. Trigger vlan_dev_hard_header path leading to NULL dereference

How to detect it

Inspect kernel logs and dmesg for NULL pointer dereference oops containing vlan_dev_hard_header and team device type change traces; correlate with audit logs showing teamd or ip link operations that alter master/slave relationships.

• BUG: kernel NULL pointer dereference.*vlan_dev_hard_header
• vlan_dev_hard_header+0x35/0x140 [8021q]
• team device type is changed from non-ether to ether
• Call Trace:.*mld_ifc_work.*process_one_work

What your security team should do

• Prioritize kernel updates on systems that use teaming with VLANs
• Restrict unprivileged local access where possible until patched
• Monitor kernel logs for vlan_dev_hard_header oops entries