{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2024-46847",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2024-46847"
  ],
  "published": "2024-09-27T12:40:05Z",
  "summary": "mm: vmalloc: ensure vmap_block is initialised before adding to queue",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: vmalloc: ensure vmap_block is initialised before adding to queue\n\nCommit 8c61291fd850 (\"mm: fix incorrect vbq reference in\npurge_fragmented_block\") extended the 'vmap_block' structure to contain a\n'cpu' field which is set at allocation time to the id of the initialising\nCPU.\n\nWhen a new 'vmap_block' is being instantiated by new_vmap_block(), the\npartially initialised structure is added to the local 'vmap_block_queue'\nxarray before the 'cpu' field has been initialised.  If another CPU is\nconcurrently walking the xarray (e.g.  via vm_unmap_aliases()), then it\nmay perform an out-of-bounds access to the remote queue thanks to an\nuninitialised index.\n\nThis has been observed as UBSAN errors in Android:\n\n | Internal error: UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP\n |\n | Call trace:\n |  purge_fragmented_block+0x204/0x21c\n |  _vm_unmap_aliases+0x170/0x378\n |  vm_unmap_aliases+0x1c/0x28\n |  change_memory_common+0x1dc/0x26c\n |  set_memory_ro+0x18/0x24\n |  module_enable_ro+0x98/0x238\n |  do_init_module+0x1b0/0x310\n\nMove the initialisation of 'vb->cpu' in new_vmap_block() ahead of the\naddition to the xarray.",
  "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.6.47-1+rpt1"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "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-v6",
            "binary_version": "1:6.6.47-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.6.47+rpt-rpi-v7",
            "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"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.6.47-1+rpt1": {
            "linux_commit": "cf64a1dfecc2dc418efdd61701c1a4b185ab4761",
            "upstream_version": "6.6.47",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.6.51"
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46847"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/1b2770e27d6d952f491bb362b657e5b2713c3efd"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/6cf74e0e5e3ab5d5c9defb4c73dad54d52224671"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/3e3de7947c751509027d26b679ecd243bc9db255"
    }
  ],
  "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 vulnerable code is core mm/vmalloc block allocation, reached through ordinary local syscall activity (read/write of compressed f2fs/erofs files, dma-buf/V4L2 buffer mapping, vmalloc/vfree churn). No network protocol handler reaches it.\nAC:L - The attacker controls both sides of the race \u2014 one thread drives vm_map_ram()/new_vmap_block() while another drives vm_unmap_aliases() on a different CPU \u2014 and the window is fully preemptible (no locks held, RCU section already exited), so it can be widened and retried indefinitely; it was observed triggering spontaneously in production Android without any attacker.\nPR:L - Every path to both sides of the race (f2fs/erofs compressed file I/O, udmabuf, videobuf2, vfree of VM_FLUSH_RESET_PERMS areas) is available to a plain unprivileged local user with no capability check anywhere along the trace.\nUI:N - The attacker's own threads perform all required operations; no victim action, mount, or file open by another user is needed.\nS:U - The uninitialized read, the out-of-bounds array access and the resulting crash all occur within the kernel's own security authority, with no crossing of a VM, IOMMU or sandbox boundary.\nC:H - __per_cpu_offset[vb->cpu] is an out-of-bounds read with an unbounded 32-bit index (up to ~32 GiB past the array) that is attacker-groomable, since struct vmap_block lands in kmalloc-256 and the uninitialized cpu field can be pre-seeded via heap spray \u2014 an attacker-directed read of arbitrary kernel memory, not a bounded few-byte overread.\nI:H - The out-of-bounds load produces a fully wild vmap_block_queue pointer built from attacker-influenceable data, which is subsequently used as a lock/list target inside purge_fragmented_block(), giving corruption of memory at an attacker-steered offset.\nA:H - The bug is a confirmed kernel panic \u2014 UBSAN array-index trap on Android, or an unhandled kernel page fault on the wild __per_cpu_offset[] load \u2014 and the oops happens while holding vmap_purge_lock and vb->lock inside an RCU read section, permanently deadlocking the vmap layer for all subsequent vmalloc/vfree."
    }
  }
}