{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults  When CONFIG_DEBUG_USER=y, and cmdline \"user_debug=31\" is set, a user fault may trigger show_pte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while show_pte() is still traversing them, causing a use-after-free in show_pte().  If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table of PMD are freed when show_pte() is running.  Acquire mmap_write_lock() around show_pte() for user faults to fix the contention.  For user faults, additionally restrict that show_pte() is called only when the addr is a user-space address (addr \u003c TASK_SIZE). This is because the lock of tsk-\u003emm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications.  Keep everything unchanged for kernel faults, because the kernel is already in the \"oops\" state, acquiring a lock may risk a deadlock.",
  "id": "DEBIAN-CVE-2026-90303",
  "modified": "2026-09-18T04:47:34.008401132Z",
  "published": "2026-09-17T17:17:27.887Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-90303"
    }
  ],
  "upstream": [
    "CVE-2026-90303"
  ]
}