{"api_version":"1","generated_at":"2026-10-21T17:39:17+00:00","cve":"CVE-2026-98225","urls":{"html":"https://cve.report/CVE-2026-98225","api":"https://cve.report/api/cve/CVE-2026-98225.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-98225","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-98225"},"summary":{"title":"mm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nokmem","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nokmem\n\nWith cgroup.memory=nokmem, shrinker_memcg_alloc() bails out early and\nnever allocates an id, so shrinker->id keeps the 0 it got from the\nkzalloc() in shrinker_alloc().  __list_lru_init() then copies that 0 into\nlru->shrinker_id, where it looks like a valid bit index.\n\nNothing calls expand_shrinker_info() on nokmem either, so shrinker_nr_max\nstays 0 and every memcg ends up with an empty map (map_nr_max == 0).\n\ndeferred_split_folio() hands a real memcg to __list_lru_add() regardless\nof whether the lru is memcg aware, so the first THP queued in a cgroup\ndoes set_shrinker_bit(memcg, nid, 0) and trips the bounds check:\n\nWARNING: mm/shrinker.c:212 at set_shrinker_bit+0x7d/0x90, CPU#126\nCall Trace:\n <TASK>\n deferred_split_folio+0x18c/0x220\n map_anon_folio_pmd_nopf+0xdd/0x130\n map_anon_folio_pmd_pf+0x14/0xb0\n do_huge_pmd_anonymous_page+0x1a1/0x620\n __handle_mm_fault+0xea9/0x10d0\n handle_mm_fault+0xe5/0x320\n do_user_addr_fault+0x1cc/0x870\n exc_page_fault+0x81/0x1b0\n asm_exc_page_fault+0x27/0x30\n </TASK>\n\nHarmless, the WARN_ON_ONCE() is what keeps the out of bounds unit[] read\nfrom happening, but the id should not look valid in the first place. \nClear it before returning.\n\nTwo other spots could paper over this: drop the id in __list_lru_init()\nwhen nokmem turns memcg_aware off, or make deferred_split_folio() pass\nNULL like list_lru_add_obj() does.  Both leave shrinker->id lying around\nfor the next caller, so fix it where the id is handed out.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-10-06 09:18:09","updated_at":"2026-10-19 10:18:23"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/469c12a69ab1842a9090b6c074ffedbfd9584f9c","name":"https://git.kernel.org/stable/c/469c12a69ab1842a9090b6c074ffedbfd9584f9c","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/932cfb25e7ce98d1f93895671ec186a3087e4f80","name":"https://git.kernel.org/stable/c/932cfb25e7ce98d1f93895671ec186a3087e4f80","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-98225","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98225","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected fafaeceb89a5e2e856ff04c2cacb6cae4a2ecb67 469c12a69ab1842a9090b6c074ffedbfd9584f9c git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected fafaeceb89a5e2e856ff04c2cacb6cae4a2ecb67 932cfb25e7ce98d1f93895671ec186a3087e4f80 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 7.2","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.8 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2026","cve_id":"98225","cve":"CVE-2026-98225","epss":"0.001620000","percentile":"0.048450000","score_date":"2026-10-06","updated_at":"2026-10-07 00:14:55"},"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["mm/shrinker.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"469c12a69ab1842a9090b6c074ffedbfd9584f9c","status":"affected","version":"fafaeceb89a5e2e856ff04c2cacb6cae4a2ecb67","versionType":"git"},{"lessThan":"932cfb25e7ce98d1f93895671ec186a3087e4f80","status":"affected","version":"fafaeceb89a5e2e856ff04c2cacb6cae4a2ecb67","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["mm/shrinker.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"7.2"},{"lessThan":"7.2","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.8","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.8","versionStartIncluding":"7.2","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3","versionStartIncluding":"7.2","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nokmem\n\nWith cgroup.memory=nokmem, shrinker_memcg_alloc() bails out early and\nnever allocates an id, so shrinker->id keeps the 0 it got from the\nkzalloc() in shrinker_alloc().  __list_lru_init() then copies that 0 into\nlru->shrinker_id, where it looks like a valid bit index.\n\nNothing calls expand_shrinker_info() on nokmem either, so shrinker_nr_max\nstays 0 and every memcg ends up with an empty map (map_nr_max == 0).\n\ndeferred_split_folio() hands a real memcg to __list_lru_add() regardless\nof whether the lru is memcg aware, so the first THP queued in a cgroup\ndoes set_shrinker_bit(memcg, nid, 0) and trips the bounds check:\n\nWARNING: mm/shrinker.c:212 at set_shrinker_bit+0x7d/0x90, CPU#126\nCall Trace:\n <TASK>\n deferred_split_folio+0x18c/0x220\n map_anon_folio_pmd_nopf+0xdd/0x130\n map_anon_folio_pmd_pf+0x14/0xb0\n do_huge_pmd_anonymous_page+0x1a1/0x620\n __handle_mm_fault+0xea9/0x10d0\n handle_mm_fault+0xe5/0x320\n do_user_addr_fault+0x1cc/0x870\n exc_page_fault+0x81/0x1b0\n asm_exc_page_fault+0x27/0x30\n </TASK>\n\nHarmless, the WARN_ON_ONCE() is what keeps the out of bounds unit[] read\nfrom happening, but the id should not look valid in the first place. \nClear it before returning.\n\nTwo other spots could paper over this: drop the id in __list_lru_init()\nwhen nokmem turns memcg_aware off, or make deferred_split_folio() pass\nNULL like list_lru_add_obj() does.  Both leave shrinker->id lying around\nfor the next caller, so fix it where the id is handed out."}],"providerMetadata":{"dateUpdated":"2026-10-19T09:15:57.057Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/469c12a69ab1842a9090b6c074ffedbfd9584f9c"},{"url":"https://git.kernel.org/stable/c/932cfb25e7ce98d1f93895671ec186a3087e4f80"}],"title":"mm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nokmem","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-98225","datePublished":"2026-10-06T08:45:00.458Z","dateReserved":"2026-09-25T10:25:14.327Z","dateUpdated":"2026-10-19T09:15:57.057Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-06 09:18:09","lastModifiedDate":"2026-10-19 10:18:23","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"98225","Ordinal":"1","Title":"mm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nok","CVE":"CVE-2026-98225","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"98225","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nokmem\n\nWith cgroup.memory=nokmem, shrinker_memcg_alloc() bails out early and\nnever allocates an id, so shrinker->id keeps the 0 it got from the\nkzalloc() in shrinker_alloc().  __list_lru_init() then copies that 0 into\nlru->shrinker_id, where it looks like a valid bit index.\n\nNothing calls expand_shrinker_info() on nokmem either, so shrinker_nr_max\nstays 0 and every memcg ends up with an empty map (map_nr_max == 0).\n\ndeferred_split_folio() hands a real memcg to __list_lru_add() regardless\nof whether the lru is memcg aware, so the first THP queued in a cgroup\ndoes set_shrinker_bit(memcg, nid, 0) and trips the bounds check:\n\nWARNING: mm/shrinker.c:212 at set_shrinker_bit+0x7d/0x90, CPU#126\nCall Trace:\n <TASK>\n deferred_split_folio+0x18c/0x220\n map_anon_folio_pmd_nopf+0xdd/0x130\n map_anon_folio_pmd_pf+0x14/0xb0\n do_huge_pmd_anonymous_page+0x1a1/0x620\n __handle_mm_fault+0xea9/0x10d0\n handle_mm_fault+0xe5/0x320\n do_user_addr_fault+0x1cc/0x870\n exc_page_fault+0x81/0x1b0\n asm_exc_page_fault+0x27/0x30\n </TASK>\n\nHarmless, the WARN_ON_ONCE() is what keeps the out of bounds unit[] read\nfrom happening, but the id should not look valid in the first place. \nClear it before returning.\n\nTwo other spots could paper over this: drop the id in __list_lru_init()\nwhen nokmem turns memcg_aware off, or make deferred_split_folio() pass\nNULL like list_lru_add_obj() does.  Both leave shrinker->id lying around\nfor the next caller, so fix it where the id is handed out.","Type":"Description","Title":"mm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nok"}]}}}