{"vulnerability": "CVE-2024-50199", "sightings": [{"uuid": "c32cbc62-1c79-45c8-8217-363bb1ec8d62", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50199", "type": "seen", "source": "https://t.me/cvedetector/10169", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50199 - Linux Kernel HugeTLB Page Table Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50199 \nPublished : Nov. 8, 2024, 6:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmm/swapfile: skip HugeTLB pages for unuse_vma  \n  \nI got a bad pud error and lost a 1GB HugeTLB when calling swapoff.  The  \nproblem can be reproduced by the following steps:  \n  \n 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory.  \n 2. Swapout the above anonymous memory.  \n 3. run swapoff and we will get a bad pud error in kernel message:  \n  \n  mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)  \n  \nWe can tell that pud_clear_bad is called by pud_none_or_clear_bad in  \nunuse_pud_range() by ftrace.  And therefore the HugeTLB pages will never  \nbe freed because we lost it from page table.  We can skip HugeTLB pages  \nfor unuse_vma to fix it. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-08T07:59:42.000000Z"}, {"uuid": "ed280877-9ed6-4739-a2a7-8d7510da4a7f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50199", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}]}