{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-53121", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-53121" ], "published": "2024-12-02T13:53:05Z", "summary": "net/mlx5: fs, lock FTE when checking if active", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: fs, lock FTE when checking if active\n\nThe referenced commits introduced a two-step process for deleting FTEs:\n\n- Lock the FTE, delete it from hardware, set the hardware deletion function\n to NULL and unlock the FTE.\n- Lock the parent flow group, delete the software copy of the FTE, and\n remove it from the xarray.\n\nHowever, this approach encounters a race condition if a rule with the same\nmatch value is added simultaneously. In this scenario, fs_core may set the\nhardware deletion function to NULL prematurely, causing a panic during\nsubsequent rule deletions.\n\nTo prevent this, ensure the active flag of the FTE is checked under a lock,\nwhich will prevent the fs_core layer from attaching a new steering rule to\nan FTE that is in the process of deletion.\n\n[ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func\n[ 438.968205] ------------[ cut here ]------------\n[ 438.968654] refcount_t: decrement hit 0; leaking memory.\n[ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110\n[ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower]\n[ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8\n[ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110\n[ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90\n[ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286\n[ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000\n[ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0\n[ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0\n[ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0\n[ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0\n[ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000\n[ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0\n[ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 438.986507] Call Trace:\n[ 438.986799] \n[ 438.987070] ? __warn+0x7d/0x110\n[ 438.987426] ? refcount_warn_saturate+0xfb/0x110\n[ 438.987877] ? report_bug+0x17d/0x190\n[ 438.988261] ? prb_read_valid+0x17/0x20\n[ 438.988659] ? handle_bug+0x53/0x90\n[ 438.989054] ? exc_invalid_op+0x14/0x70\n[ 438.989458] ? asm_exc_invalid_op+0x16/0x20\n[ 438.989883] ? refcount_warn_saturate+0xfb/0x110\n[ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core]\n[ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core]\n[ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core]\n[ 438.992054] ? xas_load+0x9/0xb0\n[ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core]\n[ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core]\n[ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core]\n[ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core]\n[ 438.994728] tc_setup_cb_destroy+0xb9/0x190\n[ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower]\n[ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower]\n[ 438.996105] tc_new_tfilter+0x347/0xbc0\n[ 438.996503] ? __\n---truncated---", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.119", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-53121" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/0d568258f99f2076ab02e9234cbabbd43e12f30e" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a508c74ceae2f5a4647f67c362126516d6404ed9" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/5b47c2f47c2fe921681f4a4fe2790375e6c04cdd" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/bfba288f53192db08c68d4c568db9783fb9cb838" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/094d1a2121cee1e85ab07d74388f94809dcfb5b9" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/933ef0d17f012b653e9e6006e3f50c8d0238b5ed" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/9ca314419930f9135727e39d77e66262d5f7bef6" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The race is driven through the local netlink/tc syscall interface (RTM_NEWTFILTER/RTM_DELTFILTER \u2192 cls_flower \u2192 mlx5e TC offload \u2192 mlx5_{add,del}_flow_rules), as shown in the reporter's trace. No remote packet-driven path into concurrent same-match-value FTE add/delete exists (aRFS adds are serialized on a single-threaded workqueue).\nAC:L - The attacker controls both sides of the race: cls_flower is TCF_PROTO_OPS_DOIT_UNLOCKED, so two threads can add and delete the identical flower filter concurrently without RTNL, in an unbounded loop. The vulnerable window is wide \u2014 it spans the entire delete_fte firmware command, because del_hw_func is NULLed before the FW call while node.active is only cleared after it completes.\nPR:L - Triggering requires CAP_NET_ADMIN over the netns owning an mlx5 netdev, enforced via ns_capable() and therefore obtainable through user namespaces (unshare -Urn), and routinely held by container root when an SR-IOV VF or representor is delegated into a container. This is unprivileged-user-reachable in realistic multi-tenant SR-IOV/switchdev deployments, not real init-namespace root.\nUI:N - The attacker performs both the add and delete operations itself from its own threads; no victim action or cooperation is needed.\nS:U - The corruption and the crash are confined to the kernel's own security authority on the same host; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - The race leaves a heap object with a corrupted function pointer and a prematurely-zeroed, permanently saturated refcount that is never freed or unhashed, and desynchronizes hardware steering from software policy \u2014 in switchdev/SR-IOV deployments stale or missing FDB entries can steer tenant traffic to the wrong vport, exposing it. Choosing the higher value given the lifetime corruption is memory-safety-adjacent rather than a benign crash.\nI:H - This is not a plain NULL data dereference: an in-heap function pointer (fte->node.del_hw_func) is corrupted to NULL and then indirectly called, i.e. a control-flow transfer through a corrupted pointer, alongside reference-count corruption. Additionally the hardware rule can never be torn down once del_hw_func is NULL, so deleted steering/firewall rules persist in hardware while the operator believes they were removed.\nA:H - The next deletion of a rule on the resurrected FTE unconditionally calls a NULL function pointer, producing a kernel oops with the FTE rwsem (and tc filter state) still held, so all subsequent flow-steering and device-config operations hang permanently; on panic_on_warn systems the refcount_warn_saturate WARN alone panics the box." } } }