In the Linux kernel, the following vulnerability has been resolved:
riscv: mm: Fix the out of bound issue of vmemmap address
In sparse vmemmap model, the virtual address of vmemmap is calculated as:
((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)).
And the struct page's va can be calculated with an offset:
(vmemmap + (pfn)).
However, when initializing struct pages, kernel actually starts from the
first page from the same section that phys_ram_base belongs to. If the
first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then
we get an va below VMEMMAP_START when calculating va for it's struct page.
For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the
first page in the same section is actually pfn 0x80000. During
init_unavailable_range(), we will initialize struct page for pfn 0x80000
with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is
below VMEMMAP_START as well as PCI_IO_END.
This commit fixes this bug by introducing a new variable
'vmemmap_start_pfn' which is aligned with memory section size and using
it to calculate vmemmap address instead of phys_ram_base.
                
            Metrics
Affected Vendors & Products
References
        History
                    Mon, 03 Nov 2025 20:30:00 +0000
| Type | Values Removed | Values Added | 
|---|---|---|
| References | 
         | 
Fri, 26 Sep 2025 19:15:00 +0000
| Type | Values Removed | Values Added | 
|---|---|---|
| Weaknesses | CWE-125 | |
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.13:rc1:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.13:rc2:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.13:rc3:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.13:rc4:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.13:rc5:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.13:rc6:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.8:-:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.8:rc7:*:*:*:*:*:*  | 
|
| Metrics | 
        
        
        cvssV3_1
         
  | 
    
        
        
        cvssV3_1
         
  | 
Thu, 22 May 2025 13:00:00 +0000
| Type | Values Removed | Values Added | 
|---|---|---|
| References | 
         | 
Wed, 22 Jan 2025 02:30:00 +0000
| Type | Values Removed | Values Added | 
|---|---|---|
| References | 
         | |
| Metrics | 
        
        
        threat_severity
         
  | 
    
        
        cvssV3_1
         
 
  | 
Tue, 21 Jan 2025 12:30:00 +0000
| Type | Values Removed | Values Added | 
|---|---|---|
| Description | In the Linux kernel, the following vulnerability has been resolved: riscv: mm: Fix the out of bound issue of vmemmap address In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)). However, when initializing struct pages, kernel actually starts from the first page from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below VMEMMAP_START when calculating va for it's struct page. For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During init_unavailable_range(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below VMEMMAP_START as well as PCI_IO_END. This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address instead of phys_ram_base. | |
| Title | riscv: mm: Fix the out of bound issue of vmemmap address | |
| References | 
         | 
Status: PUBLISHED
Assigner: Linux
Published: 2025-01-21T12:18:12.548Z
Updated: 2025-11-03T19:32:46.584Z
Reserved: 2025-01-19T11:50:08.380Z
Link: CVE-2024-57945
No data.
Status : Modified
Published: 2025-01-21T13:15:09.033
Modified: 2025-11-03T20:16:55.583
Link: CVE-2024-57945