{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2024-38663",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2024-38663"
  ],
  "published": "2024-06-24T13:51:08Z",
  "summary": "blk-cgroup: fix list corruption from resetting io stat",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: fix list corruption from resetting io stat\n\nSince commit 3b8cc6298724 (\"blk-cgroup: Optimize blkcg_rstat_flush()\"),\neach iostat instance is added to blkcg percpu list, so blkcg_reset_stats()\ncan't reset the stat instance by memset(), otherwise the llist may be\ncorrupted.\n\nFix the issue by only resetting the counter part.",
  "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.20-1+rpt1",
        "1:6.6.28-1+rpt1",
        "1:6.6.31-1+rpt1"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "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-v6",
            "binary_version": "1:6.6.20-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.6.20+rpt-rpi-v7",
            "binary_version": "1:6.6.20-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.6.20+rpt-rpi-v7l",
            "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-v6",
            "binary_version": "1:6.6.28-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.6.28+rpt-rpi-v7",
            "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-v6",
            "binary_version": "1:6.6.31-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.6.31+rpt-rpi-v7",
            "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"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.6.20-1+rpt1": {
            "linux_commit": "6f16847710cc0502450788b9f12f0a14d3429668",
            "upstream_version": "6.6.20",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.6.33"
          },
          "1:6.6.28-1+rpt1": {
            "linux_commit": "0c341f47adc3578cd5f817aa20ee2b7f9ae6b23e",
            "upstream_version": "6.6.28",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.6.33"
          },
          "1:6.6.31-1+rpt1": {
            "linux_commit": "c1432b4bae5b6582f4d32ba381459f33c34d1424",
            "upstream_version": "6.6.31",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.6.33"
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-38663"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/d4a60298ac34f027a09f8f893fdbd9e06279bb24"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/89bb36c72e1951843f9e04dc84412e31fcc849a9"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/6da6680632792709cecf2b006f2fe3ca7857e791"
    }
  ],
  "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 vulnerability is triggered by writing to the cgroup v1 control file `blkio.reset_stats` and by submitting block I/O from the same cgroup, both of which require local access to the machine (cgroupfs write + write(2)/read(2) to a block device or file). There is no network, adjacent-network, or physical path into `blkcg_reset_stats()`.\nAC:L - The attacker controls both sides of the race: they generate I/O inside their own cgroup to populate `blkcg->lhead` via `blk_cgroup_bio_start()` and concurrently write `blkio.reset_stats` in a loop from another thread, and `blkcg_reset_stats()` takes only `blkcg->lock`, which the I/O path never acquires. Once `lqueued` is cleared on a still-linked node, the very next bio deterministically re-adds it and forms a cycle \u2014 no memory layout or timing outside the attacker's influence is needed, and failed attempts can be retried indefinitely.\nPR:L - `cgroup_kn_set_ugid()` explicitly sets cgroup directories and control files to the uid/gid of their creator, so an unprivileged user or container root with write access to a delegated cgroup v1 blkio subtree (standard in LXC/LXD, Docker/Kubernetes, and systemd `Delegate=` setups) can `mkdir` a child cgroup and own its `blkio.reset_stats` file, then generate I/O and write it. No init-namespace root or capability is required, and the resulting lockless-list corruption is not confined to the attacker's own cgroup \u2014 it hangs the whole machine.\nUI:N - The attacker performs both the I/O submission and the `blkio.reset_stats` write from their own processes; no victim has to mount, open, or otherwise interact with anything.\nS:U - The corrupted `blkg_iostat_set` lockless lists and the resulting crash/corruption are entirely within the kernel's own security authority; no VM, hypervisor, or IOMMU boundary is crossed by the bug itself.\nC:H - This is a memory-corruption defect \u2014 `memset()` over live `llist_node` linkage and the `lqueued` membership flag inside per-CPU `blkg_iostat_set` objects \u2014 which desynchronizes the list-membership invariant that the blkg lifetime rules depend on (in the v6.2\u2013v6.4 part of the affected range llist membership held a `percpu_ref` on `blkg->refcnt`, so lost/duplicated puts corrupt `struct blkcg_gq` lifetime accounting). The same broken invariant in this exact function has since produced a confirmed slab use-after-free in `__blkcg_rstat_flush()`, and dangling/looped links into kmalloc'd blkg and per-CPU stat memory are leverageable for kernel memory disclosure via heap grooming.\nI:H - The corrupted links cause `__blkcg_rstat_flush()` to write unbounded, attacker-influenced counter deltas through the cyclic chain into ancestor blkgs' `iostat` (`blkcg_iostat_update(parent, ...)`), modifying kernel state belonging to higher-privileged cgroups, and the underlying pointer/refcount corruption of `struct blkcg_gq` is the classic primitive for heap grooming and writes through stale pointers. Per kernel CNA practice, list corruption of this class is treated as exploitable for control-flow-relevant memory modification.\nA:H - The reliable, immediate outcome is a cyclic lockless list that makes `llist_for_each_entry_safe()` in `__blkcg_rstat_flush()` spin forever while holding the global `raw_spinlock_t blkg_stat_lock` with local IRQs disabled \u2014 every other CPU entering rstat flush then spins too, producing a hard lockup and watchdog panic. Additionally, the `memset`-to-`bis->blkg = blkg` window lets a concurrent flush dereference a NULL `blkg`, and the truncated chains permanently leak blkg references and per-CPU stats."
    }
  }
}