|
Bugzilla – Full Text Bug Listing |
| Summary: | VUL-0: CVE-2024-35993: kernel: mm: turn folio_test_hugetlb into a PageType | ||
|---|---|---|---|
| Product: | [Novell Products] SUSE Security Incidents | Reporter: | SMASH SMASH <smash_bz> |
| Component: | Incidents | Assignee: | Oscar Salvador <osalvador> |
| Status: | IN_PROGRESS --- | QA Contact: | Security Team bot <security-team> |
| Severity: | Normal | ||
| Priority: | P3 - Medium | CC: | gianluca.gabrielli, mhocko |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| URL: | https://smash.suse.de/issue/406722/ | ||
| Whiteboard: | |||
| Found By: | Security Response Team | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Oscar, you might want to double check but AFAICS this is VM_BUG_ON only so in none of our kernels this should blow up. I do not see any other potential security implications. Yes, we can only blow up on DEBUG_VM, because: >static inline bool folio_test_hugetlb(struct folio *folio) >{ > return folio_test_large(folio) && > test_bit(PG_hugetlb, folio_flags(folio, 1)); >} >static unsigned long *folio_flags(struct folio *folio, unsigned n) >{ > struct page *page = &folio->page; > > VM_BUG_ON_PGFLAGS(PageTail(page), page); > VM_BUG_ON_PGFLAGS(n > 0 && !test_bit(PG_head, &page->flags), page); > return &page[n].flags; >} Basically what happens is that folio_test_large, which checks PG_head returned true, but folio_flags() blows up because by the time we call in, PG_head has vanished, which means that the page has changed throughout the check. While it is true that we only crash onDEBUG_VM, this fixes a more fundamental issue which is having the check for PageHuge in a deterministic way, so I am leaning towards backporting this anyway, not as a security fix, but as a fix in general. Unless there are objections. |
In the Linux kernel, the following vulnerability has been resolved: mm: turn folio_test_hugetlb into a PageType The current folio_test_hugetlb() can be fooled by a concurrent folio split into returning true for a folio which has never belonged to hugetlbfs. This can't happen if the caller holds a refcount on it, but we have a few places (memory-failure, compaction, procfs) which do not and should not take a speculative reference. Since hugetlb pages do not use individual page mapcounts (they are always fully mapped and use the entire_mapcount field to record the number of mappings), the PageType field is available now that page_mapcount() ignores the value in this field. In compaction and with CONFIG_DEBUG_VM enabled, the current implementation can result in an oops, as reported by Luis. This happens since 9c5ccf2db04b ("mm: remove HUGETLB_PAGE_DTOR") effectively added some VM_BUG_ON() checks in the PageHuge() testing path. [willy@infradead.org: update vmcoreinfo] Link: https://lkml.kernel.org/r/ZgGZUvsdhaT1Va-T@casper.infradead.org References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-35993 https://www.cve.org/CVERecord?id=CVE-2024-35993 https://git.kernel.org/stable/c/2431b5f2650dfc47ce782d1ca7b02d6b3916976f https://git.kernel.org/stable/c/9fdcc5b6359dfdaa52a55033bf50e2cedd66eb32 https://git.kernel.org/stable/c/d99e3140a4d33e26066183ff727d8f02f56bec64 https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-35993.mbox