{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.19.10-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  mm: Fix a hmm_range_fault() livelock / starvation problem  If hmm_range_fault() fails a folio_trylock() in do_swap_page, trying to acquire the lock of a device-private folio for migration, to ram, the function will spin until it succeeds grabbing the lock.  However, if the process holding the lock is depending on a work item to be completed, which is scheduled on the same CPU as the spinning hmm_range_fault(), that work item might be starved and we end up in a livelock / starvation situation which is never resolved.  This can happen, for example if the process holding the device-private folio lock is stuck in    migrate_device_unmap()-\u003elru_add_drain_all() sinc lru_add_drain_all() requires a short work-item to be run on all online cpus to complete.  A prerequisite for this to happen is: a) Both zone device and system memory folios are considered in    migrate_device_unmap(), so that there is a reason to call    lru_add_drain_all() for a system memory folio while a    folio lock is held on a zone device folio. b) The zone device folio has an initial mapcount \u003e 1 which causes    at least one migration PTE entry insertion to be deferred to    try_to_migrate(), which can happen after the call to    lru_add_drain_all(). c) No or voluntary only preemption.  This all seems pretty unlikely to happen, but indeed is hit by the \"xe_exec_system_allocator\" igt test.  Resolve this by waiting for the folio to be unlocked if the folio_trylock() fails in do_swap_page().  Rename migration_entry_wait_on_locked() to softleaf_entry_wait_unlock() and update its documentation to indicate the new use-case.  Future code improvements might consider moving the lru_add_drain_all() call in migrate_device_unmap() to be called *after* all pages have migration entries inserted. That would eliminate also b) above.  v2: - Instead of a cond_resched() in hmm_range_fault(),   eliminate the problem by waiting for the folio to be unlocked   in do_swap_page() (Alistair Popple, Andrew Morton) v3: - Add a stub migration_entry_wait_on_locked() for the   !CONFIG_MIGRATION case. (Kernel Test Robot) v4: - Rename migrate_entry_wait_on_locked() to   softleaf_entry_wait_on_locked() and update docs (Alistair Popple) v5: - Add a WARN_ON_ONCE() for the !CONFIG_MIGRATION   version of softleaf_entry_wait_on_locked(). - Modify wording around function names in the commit message   (Andrew Morton)  (cherry picked from commit a69d1ab971a624c6f112cea61536569d579c3215)",
  "id": "DEBIAN-CVE-2026-43404",
  "modified": "2026-09-14T16:47:40.650767222Z",
  "published": "2026-05-08T15:16:51.887Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-43404"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-43404"
  ]
}