| From bippy-1.2.0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@kernel.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2025-37922: book3s64/radix : Align section vmemmap start address to PAGE_SIZE |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| book3s64/radix : Align section vmemmap start address to PAGE_SIZE |
| |
| A vmemmap altmap is a device-provided region used to provide |
| backing storage for struct pages. For each namespace, the altmap |
| should belong to that same namespace. If the namespaces are |
| created unaligned, there is a chance that the section vmemmap |
| start address could also be unaligned. If the section vmemmap |
| start address is unaligned, the altmap page allocated from the |
| current namespace might be used by the previous namespace also. |
| During the free operation, since the altmap is shared between two |
| namespaces, the previous namespace may detect that the page does |
| not belong to its altmap and incorrectly assume that the page is a |
| normal page. It then attempts to free the normal page, which leads |
| to a kernel crash. |
| |
| Kernel attempted to read user page (18) - exploit attempt? (uid: 0) |
| BUG: Kernel NULL pointer dereference on read at 0x00000018 |
| Faulting instruction address: 0xc000000000530c7c |
| Oops: Kernel access of bad area, sig: 11 [#1] |
| LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries |
| CPU: 32 PID: 2104 Comm: ndctl Kdump: loaded Tainted: G W |
| NIP: c000000000530c7c LR: c000000000530e00 CTR: 0000000000007ffe |
| REGS: c000000015e57040 TRAP: 0300 Tainted: G W |
| MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 84482404 |
| CFAR: c000000000530dfc DAR: 0000000000000018 DSISR: 40000000 IRQMASK: 0 |
| GPR00: c000000000530e00 c000000015e572e0 c000000002c5cb00 c00c000101008040 |
| GPR04: 0000000000000000 0000000000000007 0000000000000001 000000000000001f |
| GPR08: 0000000000000005 0000000000000000 0000000000000018 0000000000002000 |
| GPR12: c0000000001d2fb0 c0000060de6b0080 0000000000000000 c0000060dbf90020 |
| GPR16: c00c000101008000 0000000000000001 0000000000000000 c000000125b20f00 |
| GPR20: 0000000000000001 0000000000000000 ffffffffffffffff c00c000101007fff |
| GPR24: 0000000000000001 0000000000000000 0000000000000000 0000000000000000 |
| GPR28: 0000000004040201 0000000000000001 0000000000000000 c00c000101008040 |
| NIP [c000000000530c7c] get_pfnblock_flags_mask+0x7c/0xd0 |
| LR [c000000000530e00] free_unref_page_prepare+0x130/0x4f0 |
| Call Trace: |
| free_unref_page+0x50/0x1e0 |
| free_reserved_page+0x40/0x68 |
| free_vmemmap_pages+0x98/0xe0 |
| remove_pte_table+0x164/0x1e8 |
| remove_pmd_table+0x204/0x2c8 |
| remove_pud_table+0x1c4/0x288 |
| remove_pagetable+0x1c8/0x310 |
| vmemmap_free+0x24/0x50 |
| section_deactivate+0x28c/0x2a0 |
| __remove_pages+0x84/0x110 |
| arch_remove_memory+0x38/0x60 |
| memunmap_pages+0x18c/0x3d0 |
| devm_action_release+0x30/0x50 |
| release_nodes+0x68/0x140 |
| devres_release_group+0x100/0x190 |
| dax_pmem_compat_release+0x44/0x80 [dax_pmem_compat] |
| device_for_each_child+0x8c/0x100 |
| [dax_pmem_compat_remove+0x2c/0x50 [dax_pmem_compat] |
| nvdimm_bus_remove+0x78/0x140 [libnvdimm] |
| device_remove+0x70/0xd0 |
| |
| Another issue is that if there is no altmap, a PMD-sized vmemmap |
| page will be allocated from RAM, regardless of the alignment of |
| the section start address. If the section start address is not |
| aligned to the PMD size, a VM_BUG_ON will be triggered when |
| setting the PMD-sized page to page table. |
| |
| In this patch, we are aligning the section vmemmap start address |
| to PAGE_SIZE. After alignment, the start address will not be |
| part of the current namespace, and a normal page will be allocated |
| for the vmemmap mapping of the current section. For the remaining |
| sections, altmaps will be allocated. During the free operation, |
| the normal page will be correctly freed. |
| |
| In the same way, a PMD_SIZE vmemmap page will be allocated only if |
| the section start address is PMD_SIZE-aligned; otherwise, it will |
| fall back to a PAGE-sized vmemmap allocation. |
| |
| Without this patch |
| ================== |
| NS1 start NS2 start |
| _________________________________________________________ |
| | NS1 | NS2 | |
| --------------------------------------------------------- |
| | Altmap| Altmap | .....|Altmap| Altmap | ........... |
| | NS1 | NS1 | | NS2 | NS2 | |
| |
| In the above scenario, NS1 and NS2 are two namespaces. The vmemmap |
| for NS1 comes from Altmap NS1, which belongs to NS1, and the |
| vmemmap for NS2 comes from Altmap NS2, which belongs to NS2. |
| |
| The vmemmap start for NS2 is not aligned, so Altmap NS2 is shared |
| by both NS1 and NS2. During the free operation in NS1, Altmap NS2 |
| is not part of NS1's altmap, causing it to attempt to free an |
| invalid page. |
| |
| With this patch |
| =============== |
| NS1 start NS2 start |
| _________________________________________________________ |
| | NS1 | NS2 | |
| --------------------------------------------------------- |
| | Altmap| Altmap | .....| Normal | Altmap | Altmap |....... |
| | NS1 | NS1 | | Page | NS2 | NS2 | |
| |
| If the vmemmap start for NS2 is not aligned then we are allocating |
| a normal page. NS1 and NS2 vmemmap will be freed correctly. |
| |
| The Linux kernel CVE team has assigned CVE-2025-37922 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 6.6 with commit 368a0590d954a659b16ab945328ada0cc10f93a0 and fixed in 6.6.90 with commit 9a8d4d7072d4df108479b1adc4b0840e96f6f61d |
| Issue introduced in 6.6 with commit 368a0590d954a659b16ab945328ada0cc10f93a0 and fixed in 6.12.28 with commit 7f5476d80f2cb364701cd1fa138a14b241ca99e9 |
| Issue introduced in 6.6 with commit 368a0590d954a659b16ab945328ada0cc10f93a0 and fixed in 6.14.6 with commit 400be767deaf31a073c6d14c5d151ae5ac2a60e2 |
| Issue introduced in 6.6 with commit 368a0590d954a659b16ab945328ada0cc10f93a0 and fixed in 6.15 with commit 9cf7e13fecbab0894f6986fc6986ab2eba8de52e |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2025-37922 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| arch/powerpc/mm/book3s64/radix_pgtable.c |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/9a8d4d7072d4df108479b1adc4b0840e96f6f61d |
| https://git.kernel.org/stable/c/7f5476d80f2cb364701cd1fa138a14b241ca99e9 |
| https://git.kernel.org/stable/c/400be767deaf31a073c6d14c5d151ae5ac2a60e2 |
| https://git.kernel.org/stable/c/9cf7e13fecbab0894f6986fc6986ab2eba8de52e |
