{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-53153",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-53153"
  ],
  "published": "2026-06-25T08:41:40Z",
  "summary": "mm/list_lru: drain before clearing xarray entry on reparent",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/list_lru: drain before clearing xarray entry on reparent\n\nmemcg_reparent_list_lrus() clears the dying memcg's xarray entry with\nxas_store(&xas, NULL) before reparenting its per-node lists into the\nparent.  This opens a window where a concurrent list_lru_del() arriving\nfor the dying memcg sees xa_load() == NULL, walks to the parent in\nlock_list_lru_of_memcg(), takes the parent's per-node lock, and calls\nlist_del_init() on an item still physically linked on the dying memcg's\nlist.\n\nIf another in-flight thread holds the dying memcg's per-node lock at the\nsame moment (another list_lru_del, or a list_lru_walk_one running an\nisolate callback), both threads modify ->next/->prev pointers on the same\nphysical list under different locks.  Adjacent items can corrupt each\nother's links.\n\nFix it by reversing the order: reparent each per-node list and mark the\nchild's list lru dead and then clear the xarray entry.  Any concurrent\nlist_lru op that finds the still-set xarray entry either takes the dying\nmemcg's per-node lock (synchronizing with the drain) or sees LONG_MIN and\nwalks to the parent, where the items now live.",
  "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:13",
        "name": "linux"
      },
      "versions": [
        "1:6.18.29-1+rpt1",
        "1:6.18.33-1+rpt1",
        "1:6.18.34-1+rpt1"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.18.29+rpt-rpi-2712",
            "binary_version": "1:6.18.29-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.29+rpt-rpi-v6",
            "binary_version": "1:6.18.29-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.29+rpt-rpi-v7",
            "binary_version": "1:6.18.29-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.29+rpt-rpi-v8",
            "binary_version": "1:6.18.29-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.29+rpt-rpi-v8-rt",
            "binary_version": "1:6.18.29-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.33+rpt-rpi-2712",
            "binary_version": "1:6.18.33-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.33+rpt-rpi-v6",
            "binary_version": "1:6.18.33-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.33+rpt-rpi-v7",
            "binary_version": "1:6.18.33-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.33+rpt-rpi-v8",
            "binary_version": "1:6.18.33-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.33+rpt-rpi-v8-rt",
            "binary_version": "1:6.18.33-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.34+rpt-rpi-2712",
            "binary_version": "1:6.18.34-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.34+rpt-rpi-v6",
            "binary_version": "1:6.18.34-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.34+rpt-rpi-v7",
            "binary_version": "1:6.18.34-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.34+rpt-rpi-v8",
            "binary_version": "1:6.18.34-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.34+rpt-rpi-v8-rt",
            "binary_version": "1:6.18.34-1+rpt1"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.18.29-1+rpt1": {
            "linux_commit": "66318c5b5cd8145a662303af12ed39ac07eb27cc",
            "upstream_version": "6.18.29",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.18.36"
          },
          "1:6.18.33-1+rpt1": {
            "linux_commit": "95b85bebbedcaedfa7ca79116ed38b7376fba412",
            "upstream_version": "6.18.33",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.18.36"
          },
          "1:6.18.34-1+rpt1": {
            "linux_commit": "c8c7494100e99ee05b11aaa4f0588a223a63d1af",
            "upstream_version": "6.18.34",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.18.36"
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53153"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/c19ff4351214f059349788e13e70e74325831ff6"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/2b66496d794e98f7aeec7688573051f22ec40bac"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/98733f3f0becb1ae0701d021c1748e974e5fa55c"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T13:16:28Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The vulnerable path is reached through local cgroup filesystem operations, primarily mkdir/rmdir and process placement in a memory cgroup, combined with local filesystem or memory-pressure activity that manipulates memcg-aware list_lru entries. It is not directly reachable by unauthenticated network packets.\nAC:L - The issue is a race, but a local attacker with control of a delegated cgroup subtree can drive both sides by repeatedly offlining cgroups while concurrently creating/removing dentries, inodes, zswap entries, or triggering shrinker activity. The race is retryable and under attacker influence, so complexity is low.\nPR:L - Creating/removing the affected cgroups requires write access to a cgroup subtree, but Linux explicitly supports delegation of cgroup subtrees to less-privileged users and cgroup namespaces. No init-namespace root-only capability is inherent once such a subtree is delegated.\nUI:N - No victim user action is needed after the attacker has local access to the relevant cgroup subtree. The attacker can trigger cgroup teardown and concurrent LRU activity directly.\nS:U - The corruption occurs within the kernel memory-management and cgroup/list_lru scope and impacts the same kernel security authority. There is no VM escape, IOMMU bypass, or separate security scope crossing.\nC:H - The bug corrupts kernel list_head next/prev pointers in memcg-aware LRUs such as dentries, inodes, zswap, and workingset shadow nodes. Such kernel memory corruption can plausibly be shaped into disclosure primitives, and uncertainty is scored at the higher severity.\nI:H - Concurrent list operations under different locks can corrupt adjacent kernel object links and later list manipulation can write through attacker-influenced pointers. This is a kernel memory corruption primitive with plausible control-flow or arbitrary-write exploitation potential.\nA:H - Even without full exploitation, corrupted kernel list links can trigger list debugging splats, oopses, panics, hangs, or reclaim/list traversal failures. Kernel crash availability impact is high."
    }
  }
}