Linux kernel
cpe:2.3:a:linux:linux_kernel:*:*:*:*:*:*:*, +4 more
- >= 6.12.0-105.debug_vm2.el10.ppc64le, < 6.12.0-105.debug_vm2.el10.ppc64le+debug
A vulnerability exists in the Linux kernel's debug virtual memory management test, specifically within the 'mm/debug_vm_pagetable' module'. This issue arises because the test manually allocates page table entries and associated memory structures but fails to properly clear these entries upon completion. As a result, stale entries can persist, potentially leading to conflicts if another process allocates a memory structure at the same address. This vulnerability has been observed in a debug kernel with 'CONFIG_DEBUG_VM_PGTABLE' enabled, where the improper handling of page table entries can cause negative values in the 'pgtables_bytes' counter, indicating a mismanagement of allocated resources.
The vulnerability can lead to a warning trace about negative 'pgtables_bytes', which reflects an incorrect accounting of page table entries. This issue can disrupt the normal functioning of processes by causing them to encounter stale page table entries, potentially leading to errors when freeing memory that has already been released.
The vulnerability can be reproduced by running the 'mm/debug_vm_pagetable' test in a Linux kernel with 'CONFIG_DEBUG_VM_PGTABLE' enabled. This test will manually allocate page table entries without properly clearing them before the test concludes. After the test runs, the 'pgtables_bytes' counter will reflect a negative value, indicating that the stale entries have not been correctly managed. This issue may not manifest every time the test is run, but it can occur if a process inadvertently accesses a stale entry during a memory management operation.
The vulnerability has been addressed in the Linux kernel by modifying the 'destroy_args' function within the 'mm/debug_vm_pgtable' module'. The updated version of this function now includes the necessary calls to clear the page table entries before freeing the associated memory structures. This patch ensures that stale entries are removed, preventing potential conflicts in future memory allocations.
Our algorithm analyzes dozens of metrics to generate these 8 key vulnerability categories, which are then combined to calculate the overall risk score.