{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-35847", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-35847" ], "published": "2024-05-17T14:47:56Z", "summary": "irqchip/gic-v3-its: Prevent double free on error", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nirqchip/gic-v3-its: Prevent double free on error\n\nThe error handling path in its_vpe_irq_domain_alloc() causes a double free\nwhen its_vpe_init() fails after successfully allocating at least one\ninterrupt. This happens because its_vpe_irq_domain_free() frees the\ninterrupts along with the area bitmap and the vprop_page and\nits_vpe_irq_domain_alloc() subsequently frees the area bitmap and the\nvprop_page again.\n\nFix this by unconditionally invoking its_vpe_irq_domain_free() which\nhandles all cases correctly and by removing the bitmap/vprop_page freeing\nfrom its_vpe_irq_domain_alloc().\n\n[ tglx: Massaged change log ]", "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", "1:6.1.47-1+rpt2", "1:6.1.47-1+rpt4", "1:6.1.54-1+rpt2", "1:6.1.58-1+rpt2", "1:6.1.63-1+rpt1", "1:6.1.73-1+rpt1", "1:6.6.20-1+rpt1", "1:6.6.28-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi1-rpi-v8", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v8", "binary_version": "1:6.1.47-1+rpt2" }, { "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.1.0-rpi4-rpi-2712", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v8", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-2712", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v8", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-2712", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v8", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-2712", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v8", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-2712", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v8", "binary_version": "1:6.6.20-1+rpt1" }, { "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-v8", "binary_version": "1:6.6.28-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.90" }, "1:6.1.47-1+rpt2": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.90" }, "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.90", "compiled_filter": false }, "1:6.1.54-1+rpt2": { "linux_commit": "2906f7abdc03d4a92b6b0e2e0c87ea2a9dffe8f7", "upstream_version": "6.1.54", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.90" }, "1:6.1.58-1+rpt2": { "linux_commit": "ccf1586ad0663fa91238ac56abf6340d6d740d18", "upstream_version": "6.1.58", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.90" }, "1:6.1.63-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.63", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.90" }, "1:6.1.73-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.73", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.90" }, "1:6.6.20-1+rpt1": { "linux_commit": "6f16847710cc0502450788b9f12f0a14d3429668", "upstream_version": "6.6.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.30" }, "1:6.6.28-1+rpt1": { "linux_commit": "0c341f47adc3578cd5f817aa20ee2b7f9ae6b23e", "upstream_version": "6.6.28", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.30" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-35847" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f5417ff561b8ac9a7e53c747b8627a7ab58378ae" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b72d2b1448b682844f995e660b77f2a1fabc1662" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/aa44d21574751a7d6bca892eb8e0e9ac68372e52" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/5dbdbe1133911ca7d8466bb86885adec32ad9438" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/dd681710ab77c8beafe2e263064cb1bd0e2d6ca9" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/03170e657f62c26834172742492a8cb8077ef792" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/5b012f77abde89bf0be8a0547636184fea618137" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/c26591afd33adce296c022e3480dea4282b7ef91" } ], "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 only path into `its_vpe_irq_domain_alloc()` is the local `/dev/kvm` ioctl chain (`KVM_CREATE_VM`/`KVM_CREATE_VCPU`/`KVM_CREATE_DEVICE`/`KVM_DEV_ARM_ VGIC_CTRL_INIT` \u2192 `vgic_v4_init()` \u2192 `its_alloc_vcpu_irqs()`). No network, adjacent, or remote-peer input reaches this code.\nAC:L - The attacker deterministically creates the failure condition by exhausting the global 65536-entry `its_vpeid_ida` with its own VMs/vCPUs, then launching a multi-vCPU VM so vCPU 0 succeeds and vCPU 1 gets `-ENOSPC` \u2014 and it also chooses `nr_vcpus`, which selects the bitmap's kmalloc size class for grooming. Nothing depends on a race or on state outside the attacker's control; GICv4 hardware is the vulnerable configuration, not an attacker-uncontrolled precondition.\nPR:L - Only an unprivileged local account with an fd on `/dev/kvm` is needed \u2014 the `kvm` group on ordinary distros, world-accessible on many Android/ChromeOS/cloud images, and routinely passed into containers and untrusted-tenant VMM processes. There is no capability check on `vgic_init()`/`vgic_v4_init()`/`its_alloc_vcpu_irqs()`.\nUI:N - The attacker performs every step itself \u2014 draining the VPE ID space with its own VMs, then creating the VM whose vGIC init trips the error path. No victim action or other user's involvement is required.\nS:U - The defect and its consequences are confined to host kernel memory within a single security authority; no VM-escape, IOMMU, or sandbox boundary is crossed by the corruption itself.\nC:H - The `kmalloc()` inside the second `free_lpi_range()` reallocates the just-freed bitmap as a live `struct lpi_range`, which is then freed again, leaving a list-linked object on the slab freelist \u2014 a use-after-free the attacker can realloc and read back, giving uncontrolled disclosure of kernel memory. The duplicated `free_lpi_range()` additionally hands identical LPI IDs to two different devices/VMs, aliasing interrupt configuration and pending state across owners.\nI:H - The same dangling `lpi_range` can be re-allocated with attacker-controlled bytes, so `merge_lpi_ranges()`/`list_del()` operate on a forged `list_head` \u2014 a write-what-where primitive suitable for control-flow hijacking and privilege escalation. The order-4 `vprop_page` is also released twice, corrupting buddy-allocator state.\nA:H - Even unexploited, the double `kfree()`/`free_pages()` trips SLUB double-free detection, page refcount underflow, or later freelist corruption, producing an oops or panic. Any local user with `/dev/kvm` can trigger it at will and repeatedly." } } }