{
  "affected": [
    {
      "ranges": [
        {
          "events": [
            {
              "introduced": "7bfe3b8ea6e30437e01fcb8e4f56ef6e4d986d0f"
            },
            {
              "fixed": "a142ca4b6481e71498712800b20e0c0fcf02843b"
            },
            {
              "fixed": "404cd6bffe17e25e0f94ed2775ffdd6cd10ac3fd"
            }
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "type": "GIT"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Linux",
        "name": "Kernel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.19.0"
            },
            {
              "fixed": "7.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "cna_assigner": "Linux",
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/43xxx/CVE-2026-43348.json"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmshv_vtl: Fix vmemmap_shift exceeding MAX_FOLIO_ORDER\n\nWhen registering VTL0 memory via MSHV_ADD_VTL0_MEMORY, the kernel\ncomputes pgmap-\u003evmemmap_shift as the number of trailing zeros in the\nOR of start_pfn and last_pfn, intending to use the largest compound\npage order both endpoints are aligned to.\n\nHowever, this value is not clamped to MAX_FOLIO_ORDER, so a\nsufficiently aligned range (e.g. physical range\n[0x800000000000, 0x800080000000), corresponding to start_pfn=0x800000000\nwith 35 trailing zeros) can produce a shift larger than what\nmemremap_pages() accepts, triggering a WARN and returning -EINVAL:\n\n  WARNING: ... memremap_pages+0x512/0x650\n  requested folio size unsupported\n\nThe MAX_FOLIO_ORDER check was added by\ncommit 646b67d57589 (\"mm/memremap: reject unreasonable folio/compound\npage sizes in memremap_pages()\").\n\nFix this by clamping vmemmap_shift to MAX_FOLIO_ORDER so we always\nrequest the largest order the kernel supports, in those cases, rather\nthan an out-of-range value.\n\nAlso fix the error path to propagate the actual error code from\ndevm_memremap_pages() instead of hard-coding -EFAULT, which was\nmasking the real -EINVAL return.",
  "id": "CVE-2026-43348",
  "modified": "2026-07-15T01:49:08.430892759Z",
  "published": "2026-05-08T13:41:51.909Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/404cd6bffe17e25e0f94ed2775ffdd6cd10ac3fd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a142ca4b6481e71498712800b20e0c0fcf02843b"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/43xxx/CVE-2026-43348.json"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43348"
    },
    {
      "type": "PACKAGE",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
    }
  ],
  "schema_version": "1.8.0",
  "summary": "mshv_vtl: Fix vmemmap_shift exceeding MAX_FOLIO_ORDER"
}