FKIE_CVE-2026-98166

Vulnerability from fkie_nvd - Published: 2026-10-06 09:17 - Updated: 2026-10-07 07:17
Severity
7.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: drm/ttm: fix swapped-out resources never leaving their bulk_move range ttm_tt_swapout() returns the number of pages swapped out on success and a negative error code on failure; for a populated ttm it never returns zero. Commit b2ed01e7ad3d ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") moved the bulk_move bookkeeping in ttm_bo_swapout_cb() under "if (!ret)", so the ttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail() pair is now skipped on every successful swapout. The equivalent change for the shrinker in commit 1d59f36e95f7 ("drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure") tests "lret > 0", which is what was intended here as well. Before b2ed01e7ad3d the resource was taken off the bulk_move before the swapout; since then a swapped-out resource stays inside its BO's bulk_move range (and on the manager LRU) although it is unevictable. When it is later freed or the BO leaves the bulk_move (ttm_resource_free(), ttm_bo_set_bulk_move() via amdgpu_vm_bo_del()), ttm_resource_del_bulk_move() skips it because of its !ttm_resource_unevictable() guard, so a range endpoint in pos->first / pos->last is left pointing at freed memory. The next ttm_lru_bulk_move_tail() or ttm_resource_add_bulk_move() on that cursor is a use-after-free, seen as the resv WARN in ttm_lru_bulk_move_add(), "list_del corruption" in ttm_resource_move_to_lru_tail() or a NULL dereference in ttm_resource_manager_next() -- minutes to hours after a hibernation, or at process exit / reboot following one. Samuel Ainsworth's analysis of drm/amd issue 5387 (see Link) identified the dangling cursor; the missing removal at swapout time is the reason it dangles. Testing the condition for success restores the removal. On an AMD Phoenix APU (ASUS UM3406GA, gfx1103) running suspend-then-hibernate on a 7.0.y stable kernel carrying the backport (Ubuntu 7.0.0-31) the bug crashed 5 of 18 hibernation cycles; a function profile of one hibernation showed 336 ttm_tt_swapout() calls and zero ttm_resource_del_bulk_move_unevictable() calls. With this change the removal happens for every swapped-out resource and 12 further cycles were clean.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/1169fe8c11ca45e3f91d59a73eb271d0ca8a7fb0
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/3db7d7d583419f7b1f2e141e36418802dbb25cf8
Impacted products
Vendor Product Version
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/gpu/drm/ttm/ttm_bo.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "1169fe8c11ca45e3f91d59a73eb271d0ca8a7fb0",
              "status": "affected",
              "version": "b2ed01e7ad3de80333e9b962a44024b094bc0b2b",
              "versionType": "git"
            },
            {
              "lessThan": "3db7d7d583419f7b1f2e141e36418802dbb25cf8",
              "status": "affected",
              "version": "b2ed01e7ad3de80333e9b962a44024b094bc0b2b",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "0124a09e3e5f5f6080efe9663b27af27933f8382",
              "versionType": "git"
            },
            {
              "lessThan": "7.1",
              "status": "affected",
              "version": "7.0.10",
              "versionType": "semver"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/gpu/drm/ttm/ttm_bo.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "7.1"
            },
            {
              "lessThan": "7.1",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.8",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3-rc4",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/ttm: fix swapped-out resources never leaving their bulk_move range\n\nttm_tt_swapout() returns the number of pages swapped out on success and\na negative error code on failure; for a populated ttm it never returns\nzero. Commit b2ed01e7ad3d (\"drm/ttm: Fix ttm_bo_swapout() infinite LRU\nwalk on swapout failure\") moved the bulk_move bookkeeping in\nttm_bo_swapout_cb() under \"if (!ret)\", so the\nttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail()\npair is now skipped on every successful swapout. The equivalent change\nfor the shrinker in commit 1d59f36e95f7 (\"drm/ttm: Fix ttm_bo_shrink()\ninfinite LRU walk on backup failure\") tests \"lret \u003e 0\", which is what\nwas intended here as well.\n\nBefore b2ed01e7ad3d the resource was taken off the bulk_move before the\nswapout; since then a swapped-out resource stays inside its BO\u0027s\nbulk_move range (and on the manager LRU) although it is unevictable.\nWhen it is later freed or the BO leaves the bulk_move\n(ttm_resource_free(), ttm_bo_set_bulk_move() via amdgpu_vm_bo_del()),\nttm_resource_del_bulk_move() skips it because of its\n!ttm_resource_unevictable() guard, so a range endpoint in pos-\u003efirst /\npos-\u003elast is left pointing at freed memory. The next\nttm_lru_bulk_move_tail() or ttm_resource_add_bulk_move() on that cursor\nis a use-after-free, seen as the resv WARN in ttm_lru_bulk_move_add(),\n\"list_del corruption\" in ttm_resource_move_to_lru_tail() or a NULL\ndereference in ttm_resource_manager_next() -- minutes to hours after a\nhibernation, or at process exit / reboot following one. Samuel\nAinsworth\u0027s analysis of drm/amd issue 5387 (see Link) identified the\ndangling cursor; the missing removal at swapout time is the reason it\ndangles.\n\nTesting the condition for success restores the removal. On an AMD\nPhoenix APU (ASUS UM3406GA, gfx1103) running suspend-then-hibernate on\na 7.0.y stable kernel carrying the backport (Ubuntu 7.0.0-31) the bug\ncrashed 5 of 18 hibernation cycles; a function profile of one\nhibernation showed 336 ttm_tt_swapout() calls and zero\nttm_resource_del_bulk_move_unevictable() calls. With this change the\nremoval happens for every swapped-out resource and 12 further cycles\nwere clean."
    }
  ],
  "id": "CVE-2026-98166",
  "lastModified": "2026-10-07T07:17:03.320",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 7.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.9,
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-10-06T09:17:58.033",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/1169fe8c11ca45e3f91d59a73eb271d0ca8a7fb0"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/3db7d7d583419f7b1f2e141e36418802dbb25cf8"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Received"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.