Vulnerability-Lookup

CVE-2026-43286 (GCVE-0-2026-43286)

Vulnerability from cvelistv5 – Published: 2026-05-08 13:11 – Updated: 2026-05-08 13:11

Title

mm/hugetlb: restore failed global reservations to subpool

Summary

In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore failed global reservations to subpool Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") fixed an underflow error for hstate->resv_huge_pages caused by incorrectly attributing globally requested pages to the subpool's reservation. Unfortunately, this fix also introduced the opposite problem, which would leave spool->used_hpages elevated if the globally requested pages could not be acquired. This is because while a subpool's reserve pages only accounts for what is requested and allocated from the subpool, its "used" counter keeps track of what is consumed in total, both from the subpool and globally. Thus, we need to adjust spool->used_hpages in the other direction, and make sure that globally requested pages are uncharged from the subpool's used counter. Each failed allocation attempt increments the used_hpages counter by how many pages were requested from the global pool. Ultimately, this renders the subpool unusable, as used_hpages approaches the max limit. The issue can be reproduced as follows: 1. Allocate 4 hugetlb pages 2. Create a hugetlb mount with max=4, min=2 3. Consume 2 pages globally 4. Request 3 pages from the subpool (2 from subpool + 1 from global) 4.1 hugepage_subpool_get_pages(spool, 3) succeeds. used_hpages += 3 4.2 hugetlb_acct_memory(h, 1) fails: no global pages left used_hpages -= 2 5. Subpool now has used_hpages = 1, despite not being able to successfully allocate any hugepages. It believes it can now only allocate 3 more hugepages, not 4. With each failed allocation attempt incrementing the used counter, the subpool eventually reaches a point where its used counter equals its max counter. At that point, any future allocations that try to allocate hugeTLB pages from the subpool will fail, despite the subpool not having any of its hugeTLB pages consumed by any user. Once this happens, there is no way to make the subpool usable again, since there is no way to decrement the used counter as no process is really consuming the hugeTLB pages. The underflow issue that the original commit fixes still remains fixed as well. Without this fix, used_hpages would keep on leaking if hugetlb_acct_memory() fails.

Severity ?

No CVSS data available.

Assigner

Linux

References

URL

Tags

	https://git.kernel.org/stable/c/5eac1322a7b14b8cd…
	https://git.kernel.org/stable/c/f055897c975d079a9…
	https://git.kernel.org/stable/c/1d3f9bb4c8af70304…

Impacted products

Vendor

Product

Version

Linux

Affected: a833a693a490ecff8ba377654c6d4d333718b6b1 , < 5eac1322a7b14b8cd05ec896618278b90fba7f39 (git)
Affected: a833a693a490ecff8ba377654c6d4d333718b6b1 , < f055897c975d079a90af873c791ab58cf0f6f2a5 (git)
Affected: a833a693a490ecff8ba377654c6d4d333718b6b1 , < 1d3f9bb4c8af70304d19c22e30f5d16a2d589bb5 (git)
Affected: adb5c2e55524e3a96b02c3904b0bb6d5a5404d21 (git)

Linux

Affected: 6.15
Unaffected: 0 , < 6.15 (semver)
Unaffected: 6.18.16 , ≤ 6.18.* (semver)
Unaffected: 6.19.6 , ≤ 6.19.* (semver)
Unaffected: 7.0 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "mm/hugetlb.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "5eac1322a7b14b8cd05ec896618278b90fba7f39",
              "status": "affected",
              "version": "a833a693a490ecff8ba377654c6d4d333718b6b1",
              "versionType": "git"
            },
            {
              "lessThan": "f055897c975d079a90af873c791ab58cf0f6f2a5",
              "status": "affected",
              "version": "a833a693a490ecff8ba377654c6d4d333718b6b1",
              "versionType": "git"
            },
            {
              "lessThan": "1d3f9bb4c8af70304d19c22e30f5d16a2d589bb5",
              "status": "affected",
              "version": "a833a693a490ecff8ba377654c6d4d333718b6b1",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "adb5c2e55524e3a96b02c3904b0bb6d5a5404d21",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "mm/hugetlb.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.15"
            },
            {
              "lessThan": "6.15",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.16",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.19.*",
              "status": "unaffected",
              "version": "6.19.6",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.0",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.16",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.19.6",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.0",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionStartIncluding": "6.14.8",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: restore failed global reservations to subpool\n\nCommit a833a693a490 (\"mm: hugetlb: fix incorrect fallback for subpool\")\nfixed an underflow error for hstate-\u003eresv_huge_pages caused by incorrectly\nattributing globally requested pages to the subpool\u0027s reservation.\n\nUnfortunately, this fix also introduced the opposite problem, which would\nleave spool-\u003eused_hpages elevated if the globally requested pages could\nnot be acquired.  This is because while a subpool\u0027s reserve pages only\naccounts for what is requested and allocated from the subpool, its \"used\"\ncounter keeps track of what is consumed in total, both from the subpool\nand globally.  Thus, we need to adjust spool-\u003eused_hpages in the other\ndirection, and make sure that globally requested pages are uncharged from\nthe subpool\u0027s used counter.\n\nEach failed allocation attempt increments the used_hpages counter by how\nmany pages were requested from the global pool.  Ultimately, this renders\nthe subpool unusable, as used_hpages approaches the max limit.\n\nThe issue can be reproduced as follows:\n1. Allocate 4 hugetlb pages\n2. Create a hugetlb mount with max=4, min=2\n3. Consume 2 pages globally\n4. Request 3 pages from the subpool (2 from subpool + 1 from global)\n\t4.1 hugepage_subpool_get_pages(spool, 3) succeeds.\n\t\tused_hpages += 3\n\t4.2 hugetlb_acct_memory(h, 1) fails: no global pages left\n\t\tused_hpages -= 2\n5. Subpool now has used_hpages = 1, despite not being able to\n   successfully allocate any hugepages. It believes it can now only\n   allocate 3 more hugepages, not 4.\n\nWith each failed allocation attempt incrementing the used counter, the\nsubpool eventually reaches a point where its used counter equals its\nmax counter.  At that point, any future allocations that try to\nallocate hugeTLB pages from the subpool will fail, despite the subpool\nnot having any of its hugeTLB pages consumed by any user.\n\nOnce this happens, there is no way to make the subpool usable again,\nsince there is no way to decrement the used counter as no process is\nreally consuming the hugeTLB pages.\n\nThe underflow issue that the original commit fixes still remains fixed\nas well.\n\nWithout this fix, used_hpages would keep on leaking if\nhugetlb_acct_memory() fails."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-08T13:11:11.867Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/5eac1322a7b14b8cd05ec896618278b90fba7f39"
        },
        {
          "url": "https://git.kernel.org/stable/c/f055897c975d079a90af873c791ab58cf0f6f2a5"
        },
        {
          "url": "https://git.kernel.org/stable/c/1d3f9bb4c8af70304d19c22e30f5d16a2d589bb5"
        }
      ],
      "title": "mm/hugetlb: restore failed global reservations to subpool",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-43286",
    "datePublished": "2026-05-08T13:11:11.867Z",
    "dateReserved": "2026-05-01T14:12:55.999Z",
    "dateUpdated": "2026-05-08T13:11:11.867Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-43286\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-05-08T14:16:35.473\",\"lastModified\":\"2026-05-08T14:16:35.473\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nmm/hugetlb: restore failed global reservations to subpool\\n\\nCommit a833a693a490 (\\\"mm: hugetlb: fix incorrect fallback for subpool\\\")\\nfixed an underflow error for hstate-\u003eresv_huge_pages caused by incorrectly\\nattributing globally requested pages to the subpool\u0027s reservation.\\n\\nUnfortunately, this fix also introduced the opposite problem, which would\\nleave spool-\u003eused_hpages elevated if the globally requested pages could\\nnot be acquired.  This is because while a subpool\u0027s reserve pages only\\naccounts for what is requested and allocated from the subpool, its \\\"used\\\"\\ncounter keeps track of what is consumed in total, both from the subpool\\nand globally.  Thus, we need to adjust spool-\u003eused_hpages in the other\\ndirection, and make sure that globally requested pages are uncharged from\\nthe subpool\u0027s used counter.\\n\\nEach failed allocation attempt increments the used_hpages counter by how\\nmany pages were requested from the global pool.  Ultimately, this renders\\nthe subpool unusable, as used_hpages approaches the max limit.\\n\\nThe issue can be reproduced as follows:\\n1. Allocate 4 hugetlb pages\\n2. Create a hugetlb mount with max=4, min=2\\n3. Consume 2 pages globally\\n4. Request 3 pages from the subpool (2 from subpool + 1 from global)\\n\\t4.1 hugepage_subpool_get_pages(spool, 3) succeeds.\\n\\t\\tused_hpages += 3\\n\\t4.2 hugetlb_acct_memory(h, 1) fails: no global pages left\\n\\t\\tused_hpages -= 2\\n5. Subpool now has used_hpages = 1, despite not being able to\\n   successfully allocate any hugepages. It believes it can now only\\n   allocate 3 more hugepages, not 4.\\n\\nWith each failed allocation attempt incrementing the used counter, the\\nsubpool eventually reaches a point where its used counter equals its\\nmax counter.  At that point, any future allocations that try to\\nallocate hugeTLB pages from the subpool will fail, despite the subpool\\nnot having any of its hugeTLB pages consumed by any user.\\n\\nOnce this happens, there is no way to make the subpool usable again,\\nsince there is no way to decrement the used counter as no process is\\nreally consuming the hugeTLB pages.\\n\\nThe underflow issue that the original commit fixes still remains fixed\\nas well.\\n\\nWithout this fix, used_hpages would keep on leaking if\\nhugetlb_acct_memory() fails.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/1d3f9bb4c8af70304d19c22e30f5d16a2d589bb5\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/5eac1322a7b14b8cd05ec896618278b90fba7f39\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/f055897c975d079a90af873c791ab58cf0f6f2a5\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}

GHSA-GHPP-GWGC-8PQ9

Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-08 15:31

Details

In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb: restore failed global reservations to subpool

Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") fixed an underflow error for hstate->resv_huge_pages caused by incorrectly attributing globally requested pages to the subpool's reservation.

Unfortunately, this fix also introduced the opposite problem, which would leave spool->used_hpages elevated if the globally requested pages could not be acquired. This is because while a subpool's reserve pages only accounts for what is requested and allocated from the subpool, its "used" counter keeps track of what is consumed in total, both from the subpool and globally. Thus, we need to adjust spool->used_hpages in the other direction, and make sure that globally requested pages are uncharged from the subpool's used counter.

Each failed allocation attempt increments the used_hpages counter by how many pages were requested from the global pool. Ultimately, this renders the subpool unusable, as used_hpages approaches the max limit.

The issue can be reproduced as follows: 1. Allocate 4 hugetlb pages 2. Create a hugetlb mount with max=4, min=2 3. Consume 2 pages globally 4. Request 3 pages from the subpool (2 from subpool + 1 from global) 4.1 hugepage_subpool_get_pages(spool, 3) succeeds. used_hpages += 3 4.2 hugetlb_acct_memory(h, 1) fails: no global pages left used_hpages -= 2 5. Subpool now has used_hpages = 1, despite not being able to successfully allocate any hugepages. It believes it can now only allocate 3 more hugepages, not 4.

With each failed allocation attempt incrementing the used counter, the subpool eventually reaches a point where its used counter equals its max counter. At that point, any future allocations that try to allocate hugeTLB pages from the subpool will fail, despite the subpool not having any of its hugeTLB pages consumed by any user.

Once this happens, there is no way to make the subpool usable again, since there is no way to decrement the used counter as no process is really consuming the hugeTLB pages.

The underflow issue that the original commit fixes still remains fixed as well.

Without this fix, used_hpages would keep on leaking if hugetlb_acct_memory() fails.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-43286"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-08T14:16:35Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: restore failed global reservations to subpool\n\nCommit a833a693a490 (\"mm: hugetlb: fix incorrect fallback for subpool\")\nfixed an underflow error for hstate-\u003eresv_huge_pages caused by incorrectly\nattributing globally requested pages to the subpool\u0027s reservation.\n\nUnfortunately, this fix also introduced the opposite problem, which would\nleave spool-\u003eused_hpages elevated if the globally requested pages could\nnot be acquired.  This is because while a subpool\u0027s reserve pages only\naccounts for what is requested and allocated from the subpool, its \"used\"\ncounter keeps track of what is consumed in total, both from the subpool\nand globally.  Thus, we need to adjust spool-\u003eused_hpages in the other\ndirection, and make sure that globally requested pages are uncharged from\nthe subpool\u0027s used counter.\n\nEach failed allocation attempt increments the used_hpages counter by how\nmany pages were requested from the global pool.  Ultimately, this renders\nthe subpool unusable, as used_hpages approaches the max limit.\n\nThe issue can be reproduced as follows:\n1. Allocate 4 hugetlb pages\n2. Create a hugetlb mount with max=4, min=2\n3. Consume 2 pages globally\n4. Request 3 pages from the subpool (2 from subpool + 1 from global)\n\t4.1 hugepage_subpool_get_pages(spool, 3) succeeds.\n\t\tused_hpages += 3\n\t4.2 hugetlb_acct_memory(h, 1) fails: no global pages left\n\t\tused_hpages -= 2\n5. Subpool now has used_hpages = 1, despite not being able to\n   successfully allocate any hugepages. It believes it can now only\n   allocate 3 more hugepages, not 4.\n\nWith each failed allocation attempt incrementing the used counter, the\nsubpool eventually reaches a point where its used counter equals its\nmax counter.  At that point, any future allocations that try to\nallocate hugeTLB pages from the subpool will fail, despite the subpool\nnot having any of its hugeTLB pages consumed by any user.\n\nOnce this happens, there is no way to make the subpool usable again,\nsince there is no way to decrement the used counter as no process is\nreally consuming the hugeTLB pages.\n\nThe underflow issue that the original commit fixes still remains fixed\nas well.\n\nWithout this fix, used_hpages would keep on leaking if\nhugetlb_acct_memory() fails.",
  "id": "GHSA-ghpp-gwgc-8pq9",
  "modified": "2026-05-08T15:31:22Z",
  "published": "2026-05-08T15:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43286"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1d3f9bb4c8af70304d19c22e30f5d16a2d589bb5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5eac1322a7b14b8cd05ec896618278b90fba7f39"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f055897c975d079a90af873c791ab58cf0f6f2a5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

FKIE_CVE-2026-43286

Vulnerability from fkie_nvd - Published: 2026-05-08 14:16 - Updated: 2026-05-08 14:16

Severity ?

Summary

References

	URL	Tags
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/1d3f9bb4c8af70304d19c22e30f5d16a2d589bb5
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/5eac1322a7b14b8cd05ec896618278b90fba7f39
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/f055897c975d079a90af873c791ab58cf0f6f2a5

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: restore failed global reservations to subpool\n\nCommit a833a693a490 (\"mm: hugetlb: fix incorrect fallback for subpool\")\nfixed an underflow error for hstate-\u003eresv_huge_pages caused by incorrectly\nattributing globally requested pages to the subpool\u0027s reservation.\n\nUnfortunately, this fix also introduced the opposite problem, which would\nleave spool-\u003eused_hpages elevated if the globally requested pages could\nnot be acquired.  This is because while a subpool\u0027s reserve pages only\naccounts for what is requested and allocated from the subpool, its \"used\"\ncounter keeps track of what is consumed in total, both from the subpool\nand globally.  Thus, we need to adjust spool-\u003eused_hpages in the other\ndirection, and make sure that globally requested pages are uncharged from\nthe subpool\u0027s used counter.\n\nEach failed allocation attempt increments the used_hpages counter by how\nmany pages were requested from the global pool.  Ultimately, this renders\nthe subpool unusable, as used_hpages approaches the max limit.\n\nThe issue can be reproduced as follows:\n1. Allocate 4 hugetlb pages\n2. Create a hugetlb mount with max=4, min=2\n3. Consume 2 pages globally\n4. Request 3 pages from the subpool (2 from subpool + 1 from global)\n\t4.1 hugepage_subpool_get_pages(spool, 3) succeeds.\n\t\tused_hpages += 3\n\t4.2 hugetlb_acct_memory(h, 1) fails: no global pages left\n\t\tused_hpages -= 2\n5. Subpool now has used_hpages = 1, despite not being able to\n   successfully allocate any hugepages. It believes it can now only\n   allocate 3 more hugepages, not 4.\n\nWith each failed allocation attempt incrementing the used counter, the\nsubpool eventually reaches a point where its used counter equals its\nmax counter.  At that point, any future allocations that try to\nallocate hugeTLB pages from the subpool will fail, despite the subpool\nnot having any of its hugeTLB pages consumed by any user.\n\nOnce this happens, there is no way to make the subpool usable again,\nsince there is no way to decrement the used counter as no process is\nreally consuming the hugeTLB pages.\n\nThe underflow issue that the original commit fixes still remains fixed\nas well.\n\nWithout this fix, used_hpages would keep on leaking if\nhugetlb_acct_memory() fails."
    }
  ],
  "id": "CVE-2026-43286",
  "lastModified": "2026-05-08T14:16:35.473",
  "metrics": {},
  "published": "2026-05-08T14:16:35.473",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/1d3f9bb4c8af70304d19c22e30f5d16a2d589bb5"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5eac1322a7b14b8cd05ec896618278b90fba7f39"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/f055897c975d079a90af873c791ab58cf0f6f2a5"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Received"
}

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.

Detection rules are retrieved from Rulezet.

Action not permitted

CVE-2026-43286 (GCVE-0-2026-43286)

GHSA-GHPP-GWGC-8PQ9

FKIE_CVE-2026-43286

Tags

Sightings

Nomenclature