{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-50041", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-50041" ], "published": "2024-10-21T19:40:44Z", "summary": "i40e: Fix macvlan leak by synchronizing access to mac_filter_hash", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix macvlan leak by synchronizing access to mac_filter_hash\n\nThis patch addresses a macvlan leak issue in the i40e driver caused by\nconcurrent access to vsi->mac_filter_hash. The leak occurs when multiple\nthreads attempt to modify the mac_filter_hash simultaneously, leading to\ninconsistent state and potential memory leaks.\n\nTo fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing\nvf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock),\nensuring atomic operations and preventing concurrent access.\n\nAdditionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in\ni40e_add_mac_filter() to help catch similar issues in the future.\n\nReproduction steps:\n1. Spawn VFs and configure port vlan on them.\n2. Trigger concurrent macvlan operations (e.g., adding and deleting\n\tportvlan and/or mac filters).\n3. Observe the potential memory leak and inconsistent state in the\n\tmac_filter_hash.\n\nThis synchronization ensures the integrity of the mac_filter_hash and prevents\nthe described leak.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/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.113", "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.57" }, "1:6.6.31-1+rpt1": { "linux_commit": "c1432b4bae5b6582f4d32ba381459f33c34d1424", "upstream_version": "6.6.31", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.57" }, "1:6.6.47-1+rpt1": { "linux_commit": "cf64a1dfecc2dc418efdd61701c1a4b185ab4761", "upstream_version": "6.6.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.57" }, "1:6.6.51-1+rpt1": { "linux_commit": "0094eba3f2a4338cfa6854b0b5104d02ba0fa01f", "upstream_version": "6.6.51", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.57" }, "1:6.6.51-1+rpt2": { "linux_commit": "82a50e430ef1d6eb37d78e25aa572c1f6ea56160", "upstream_version": "6.6.51", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.57" }, "1:6.6.51-1+rpt3": { "linux_commit": "5aeecea9f4a45248bcf564dec924965e066a7bfd", "upstream_version": "6.6.51", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.57" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-50041" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/9db6ce9e2738b05a3672aff4d42169cf3bb5a3e3" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/9a9747288ba0a9ad4f5c9877f18dd245770ad64e" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/703c4d820b31bcadf465288d5746c53445f02a55" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/8831abff1bd5b6bc8224f0c0671f46fbd702b5b2" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/dac6c7b3d33756d6ce09f00a96ea2ecd79fae9fb" } ], "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": 8.8, "cvss_v3_severity": "High", "scenario": "AV:L - The vulnerable code is reached only through the i40e virtchnl mailbox from an assigned SR-IOV VF (PCIe transport) or from host-side netdev operations, not from network packets. This is logical local access to the device, so Local.\nAC:L - The attacker deterministically controls the unlocked side \u2014 `vf->driver_caps` is taken verbatim from the VF message so the gating condition is attacker-selected, and `VIRTCHNL_OP_GET_VF_RESOURCES` can be replayed without limit \u2014 while pre-populating MAC/VLAN filters lengthens the unlocked hash walk, which runs in preemptible workqueue context; on lockdep kernels the assertion fires with no race needed at all.\nPR:L - The attacker is the owner of an assigned VF \u2014 a guest VM tenant or a VFIO/DPDK userspace driver \u2014 holding no privilege on the host kernel beyond the granted device, and no host-side capability, root, or trusted-VF flag is required (the path runs before any privilege check and untrusted VFs reach it).\nUI:N - The guest drives the vulnerable path entirely on its own by writing virtchnl messages to its mailbox; no victim action is needed to enable the attack, and the deterministic lockdep-assert path requires nothing from anyone else.\nS:C - The virtchnl handler is the PF's service surface for a VF that belongs to a separate security authority (guest VM / VFIO container), and successful exploitation corrupts host kernel memory \u2014 a guest-to-host boundary crossing analogous to a hypervisor escape.\nC:H - Unsynchronized `hash_for_each_safe()` racing a concurrent `kfree()` in `i40e_sync_vsi_filters()` produces a use-after-free on a kmalloc-32 `struct i40e_mac_filter`, and corrupted hlist traversal follows attacker-groomable pointers into reallocated memory, enabling kernel heap disclosure.\nI:H - `__i40e_del_filter()` writes `f->state` into freed memory and `hash_del()` performs `*pprev = next` using pointers from a reallocated, attacker-sprayed 32-byte object \u2014 a write-what-where primitive; concurrent unlink from both sides also yields a double free.\nA:H - Concurrent unlocked hlist manipulation corrupts the filter hash, causing use-after-free, double free, and lost entries (the reported leak), any of which panic the host kernel; on `CONFIG_PROVE_LOCKING` builds a guest can also trigger the `lockdep_assert_held()` WARN on demand, which is fatal under `panic_on_warn`." } } }