Executive Summary
| Informations | |||
|---|---|---|---|
| Name | CVE-2024-50199 | First vendor Publication | 2024-11-08 |
| Vendor | Cve | Last vendor Modification | 2024-11-08 |
Security-Database Scoring CVSS v3
| Cvss vector : N/A | |||
|---|---|---|---|
| Overall CVSS Score | NA | ||
| Base Score | NA | Environmental Score | NA |
| impact SubScore | NA | Temporal Score | NA |
| Exploitabality Sub Score | NA | ||
| Calculate full CVSS 3.0 Vectors scores | |||
Security-Database Scoring CVSS v2
| Cvss vector : | |||
|---|---|---|---|
| Cvss Base Score | N/A | Attack Range | N/A |
| Cvss Impact Score | N/A | Attack Complexity | N/A |
| Cvss Expoit Score | N/A | Authentication | N/A |
| Calculate full CVSS 2.0 Vectors scores | |||
Detail
| In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it. |
Original Source
| Url : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-50199 |
Sources (Detail)
Alert History
| Date | Informations |
|---|---|
| 2024-11-09 03:01:55 |
|
| 2024-11-09 03:01:13 |
|
| 2024-11-08 21:27:29 |
|
| 2024-11-08 13:27:35 |
|
