{ "schema_version": "1.6.1", "id": "RPI-CVE-2023-53484", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2023-53484" ], "published": "2025-10-01T11:43:29Z", "summary": "lib: cpu_rmap: Avoid use after free on rmap->obj array entries", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nlib: cpu_rmap: Avoid use after free on rmap->obj array entries\n\nWhen calling irq_set_affinity_notifier() with NULL at the notify\nargument, it will cause freeing of the glue pointer in the\ncorresponding array entry but will leave the pointer in the array. A\nsubsequent call to free_irq_cpu_rmap() will try to free this entry again\nleading to possible use after free.\n\nFix that by setting NULL to the array entry and checking that we have\nnon-zero at the array entry when iterating over the array in\nfree_irq_cpu_rmap().\n\nThe current code does not suffer from this since there are no cases\nwhere irq_set_affinity_notifier(irq, NULL) (note the NULL passed for the\nnotify arg) is called, followed by a call to free_irq_cpu_rmap() so we\ndon't hit and issue. Subsequent patches in this series excersize this\nflow, hence the required fix.", "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.21-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7l", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v8", "binary_version": "1:6.1.21-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.1.21-1+rpt1": { "linux_commit": "0afb5e98488aed7017b9bf321b575d0177feb7ed", "upstream_version": "6.1.21", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.30" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2023-53484" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/981f339d2905b6a92ef59358158b326493aecac5" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/d1308bd0b24cb1d78fa2747d5fa3e055cc628a48" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/cc2d2b3dbfb0ba57bc027fb7e1121250c50e4000" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f748e15253833b771acbede14ea98f50831ac289" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/c6ed54dd90698dc0744d669524cc1c122ded8a16" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/c9115f49cf260d24d8b5f2d9a4b63cb31a627bb4" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/67bca5f1d644f4e79b694abd8052a177de81c37f" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/4e0473f1060aa49621d40a113afde24818101d37" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:24:39Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The vulnerable code is reached only through local device-configuration and teardown paths (`ethtool -L`/set-channels, interface down, devlink SF/VF teardown, driver unbind) that drive `irq_cpu_rmap_remove()` and `free_irq_cpu_rmap()`. No remote packet or protocol data reaches `lib/cpu_rmap.c`; the RFS receive path only reads `rmap->near[]`, not the freed glue objects.\nAC:L - The use-after-free is deterministic and requires no race \u2014 releasing an IRQ vector leaves a stale `rmap->obj[]` entry that the subsequent `free_irq_cpu_rmap()` walk unconditionally dereferences, and the attacker fully controls the ordering and timing of both steps. `CONFIG_RFS_ACCEL` is `default y` (depends on `RPS`), so the required configuration is the norm on distro kernels, and the unbounded window between free and walk lets the attacker reliably groom the `kmalloc-64` slab.\nPR:L - Triggering requires CAP_NET_ADMIN over the affected netdev (ethtool set-channels, link down, devlink SF removal), which per kernel-CNA guidance scores as Low rather than High. In common SR-IOV/container deployments an mlx5 VF netdev is delegated into a network namespace owned by a user namespace, giving an otherwise unprivileged container-local user exactly this capability over the device.\nUI:N - No victim action is needed; the attacker performs both the IRQ-vector release and the subsequent rmap teardown entirely on their own via device reconfiguration.\nS:U - The freed object, the corrupted state, and the resulting impact are all within the kernel's own security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - This is a use-after-free on a `kmalloc-64` GFP_KERNEL object with an attacker-paced reclaim window, so the freed `struct irq_glue` can be reoccupied with sprayed data; the attacker-controlled `notify.irq` then selects an arbitrary `irq_desc`, and the resulting refcount underflow and indirect `->release` call chain can be leveraged into arbitrary kernel memory disclosure.\nI:H - After reclaiming the freed glue, `irq_set_affinity_notifier(glue->notify.irq, NULL)` performs an arbitrary IRQ-descriptor lookup and issues spurious `kref_put(&old_notify->kref, old_notify->release)` calls on a live notifier, producing refcount underflow, premature free, and an indirect call through a function pointer \u2014 a control-flow hijack primitive rather than a mere crash.\nA:H - Even unweaponized, dereferencing the freed glue and passing garbage to `irq_set_affinity_notifier()` corrupts unrelated IRQ descriptor state and oopses/panics the kernel during device teardown, and the double kref_put can prematurely free the cpu_rmap itself." } } }