{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-53088", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-53088" ], "published": "2024-11-19T17:45:17Z", "summary": "i40e: fix race condition by adding filter's intermediate sync state", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix race condition by adding filter's intermediate sync state\n\nFix a race condition in the i40e driver that leads to MAC/VLAN filters\nbecoming corrupted and leaking. Address the issue that occurs under\nheavy load when multiple threads are concurrently modifying MAC/VLAN\nfilters by setting mac and port VLAN.\n\n1. Thread T0 allocates a filter in i40e_add_filter() within\n i40e_ndo_set_vf_port_vlan().\n2. Thread T1 concurrently frees the filter in __i40e_del_filter() within\n i40e_ndo_set_vf_mac().\n3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which\n refers to the already freed filter memory, causing corruption.\n\nReproduction steps:\n1. Spawn multiple VFs.\n2. Apply a concurrent heavy load by running parallel operations to change\n MAC addresses on the VFs and change port VLANs on the host.\n3. Observe errors in dmesg:\n\"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX,\n\tplease set promiscuous on manually for VF XX\".\n\nExact code for stable reproduction Intel can't open-source now.\n\nThe fix involves implementing a new intermediate filter state,\nI40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.\nThese filters cannot be deleted from the hash list directly but\nmust be removed using the full process.", "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", "1:6.6.28-1+rpt1", "1:6.6.31-1+rpt1", "1:6.6.47-1+rpt1", "1:6.6.51-1+rpt1", "1:6.6.51-1+rpt2", "1:6.6.51-1+rpt3" ], "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" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-2712", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v7l", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v8", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-2712", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v7l", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v8", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.47+rpt-rpi-2712", "binary_version": "1:6.6.47-1+rpt1" }, { "binary_name": "linux-image-6.6.47+rpt-rpi-v7l", "binary_version": "1:6.6.47-1+rpt1" }, { "binary_name": "linux-image-6.6.47+rpt-rpi-v8", "binary_version": "1:6.6.47-1+rpt1" }, { "binary_name": "linux-image-6.6.51+rpt-rpi-2712", "binary_version": "1:6.6.51-1+rpt1" }, { "binary_name": "linux-image-6.6.51+rpt-rpi-v7l", "binary_version": "1:6.6.51-1+rpt1" }, { "binary_name": "linux-image-6.6.51+rpt-rpi-v8", "binary_version": "1:6.6.51-1+rpt1" }, { "binary_name": "linux-image-6.6.51+rpt-rpi-2712", "binary_version": "1:6.6.51-1+rpt2" }, { "binary_name": "linux-image-6.6.51+rpt-rpi-v7l", "binary_version": "1:6.6.51-1+rpt2" }, { "binary_name": "linux-image-6.6.51+rpt-rpi-v8", "binary_version": "1:6.6.51-1+rpt2" }, { "binary_name": "linux-image-6.6.51+rpt-rpi-2712", "binary_version": "1:6.6.51-1+rpt3" }, { "binary_name": "linux-image-6.6.51+rpt-rpi-v7l", "binary_version": "1:6.6.51-1+rpt3" }, { "binary_name": "linux-image-6.6.51+rpt-rpi-v8", "binary_version": "1:6.6.51-1+rpt3" } ] }, "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.117", "compiled_filter": false }, "1:6.6.28-1+rpt1": { "linux_commit": "0c341f47adc3578cd5f817aa20ee2b7f9ae6b23e", "upstream_version": "6.6.28", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.61" }, "1:6.6.31-1+rpt1": { "linux_commit": "c1432b4bae5b6582f4d32ba381459f33c34d1424", "upstream_version": "6.6.31", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.61" }, "1:6.6.47-1+rpt1": { "linux_commit": "cf64a1dfecc2dc418efdd61701c1a4b185ab4761", "upstream_version": "6.6.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.61" }, "1:6.6.51-1+rpt1": { "linux_commit": "0094eba3f2a4338cfa6854b0b5104d02ba0fa01f", "upstream_version": "6.6.51", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.61" }, "1:6.6.51-1+rpt2": { "linux_commit": "82a50e430ef1d6eb37d78e25aa572c1f6ea56160", "upstream_version": "6.6.51", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.61" }, "1:6.6.51-1+rpt3": { "linux_commit": "5aeecea9f4a45248bcf564dec924965e066a7bfd", "upstream_version": "6.6.51", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.61" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-53088" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/262dc6ea5f1eb18c4d08ad83d51222d0dd0dd42a" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/7ad3fb3bfd43feb4e15c81dffd23ac4e55742791" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/bf5f837d9fd27d32fb76df0a108babcaf4446ff1" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/6e046f4937474bc1b9fa980c1ad8f3253fc638f6" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f30490e9695ef7da3d0899c6a0293cc7cd373567" } ], "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 local socket/netlink operations on the i40e interface (multicast join/leave via setsockopt, or rtnetlink VF MAC/port-VLAN changes) which manipulate the driver's MAC/VLAN filter hash. No remote peer data reaches the vulnerable code path.\nAC:L - The attacker controls both sides of the race \u2014 creating the I40E_FILTER_NEW filter, scheduling the sync via __I40E_MACVLAN_SYNC_PENDING, and issuing the free \u2014 and the window is milliseconds wide while i40e_sync_vsi_filters() waits on firmware admin-queue commands with mac_filter_hash_lock dropped. The loop can be retried indefinitely at no cost.\nPR:L - An entirely unprivileged local user can reach __i40e_del_filter() via IP_ADD_MEMBERSHIP/IP_DROP_MEMBERSHIP, which flows through ip_mc_filter_add/del \u2192 dev_mc_add/del \u2192 i40e_set_rx_mode \u2192 i40e_addr_sync/unsync with no capability check anywhere on the path. CAP_NET_ADMIN is not required, only a local account.\nUI:N - Exploitation is fully self-driven by the attacker's own socket operations against the i40e netdev; no action by any other user or administrator is needed.\nS:U - The use-after-free corrupts host kernel heap memory managed by the same security authority as the attacker's context, i.e. standard in-kernel memory corruption and privilege escalation.\nC:H - The freed i40e_mac_filter is dereferenced for macaddr and vlan, and those stale heap bytes are programmed into the NIC's hardware filter table, so reoccupied kernel heap contents leak into observable device state; per UAF scoring this supports arbitrary read leverage.\nI:H - The sync path writes new->f->state into the freed kmalloc-32 chunk (offset 24, potentially clobbering the SLUB freelist pointer) and corrupts netdev_hw_addr refcounts, giving a spray-and-write primitive usable for control-flow hijacking; the bug also leaves stale/leaked hardware MAC filters and forces promiscuous mode.\nA:H - Use-after-free on a heavily shared kmalloc-32 cache causes slab corruption, refcount corruption and kernel panics/oopses (immediate BUG under KASAN or hardened allocators), and the filter leak degrades the interface until reset." } } }