CVE-2021-47592

What it actually does

Incorrect handling of flow_cls_offload structure during tc flower filter deletion in stmmac driver leads to use-after-free of rule dissector, resulting in NULL pointer dereference and kernel oops when deleting VLAN priority based RX steering filters.

Why it matters to the business

Systems using affected Linux kernel network drivers may experience kernel panics and reboots when traffic control rules for VLAN steering are deleted, causing denial of service and service disruption on network appliances or servers.

How an attack unfolds

An attacker with sufficient privileges to configure and delete tc flower filters on an interface using stmmac driver adds a VLAN priority filter then deletes it by preference ID, triggering the flawed tc_del_vlan_flow path that dereferences freed memory from prior flow_cls_offload_flow_rule call.

How to fix it

Update to a Linux kernel containing the fix for stmmac tc flower deletion logic that maintains driver-side stmmac_rfs_entry records instead of relying on invalidated flow_cls_offload structures.

How to confirm the fix worked

Confirm kernel version includes the stmmac patch; reproduce the tc add/del sequence and verify absence of NULL pointer oops in dmesg; inspect stmmac source for stmmac_rfs_entry usage in tc_add_vlan_flow and tc_del_vlan_flow.

Typical attack path

1. Add ingress qdisc and mqprio root qdisc on stmmac interface
2. Add flower filter matching vlan_prio with hw_tc mapping
3. Retrieve filter preference ID via tc show
4. Issue tc filter del using the preference ID
5. Kernel executes stmmac_setup_tc_block_cb leading to NULL dereference in tc_setup_cls

How to detect it

Search kernel logs and dmesg for BUG: kernel NULL pointer dereference combined with RIP referencing tc_setup_cls in stmmac module and call traces through tc_setup_cb_destroy and fl_hw_destroy_filter; correlate with prior tc filter operations on ingress qdiscs.

• BUG: kernel NULL pointer dereference.*tc_setup_cls.*stmmac
• RIP:.*tc_setup_cls.*stmmac
• Call Trace:.*stmmac_setup_tc_block_cb.*tc_setup_cb_destroy.*fl_hw_destroy_filter

What your security team should do

• Prioritize kernel updates on systems exposing stmmac interfaces to untrusted local users
• Audit use of tc flower filters with VLAN priority on affected hardware
• Monitor for kernel oops involving tc_setup_cls and stmmac in system logs
• Restrict unprivileged access to tc and netlink interfaces where possible