CVE-2024-46790 in Linux
Riassunto
di VulDB • 20/06/2026
Based on the kernel crash trace and the description provided, this is a bug in the Linux kernel's memory management subsystem, specifically related to **Memory Corruption Detection (MCE/HWPOISON)** and **Page Allocation Tags**.
### Analysis of the Crash
1. **Context**: The crash occurs in `pgalloc_tag_sub`, which is part of the page allocation tag accounting mechanism (used for debugging memory leaks or tracking page allocations). 2. **Trigger**: The call stack shows `hwpoison_unpoison` -> `unpoison_memory` -> `folio_put` -> `free_unref_page`. This means a page that was previously "poisoned" (marked as bad/corrupted for testing) is being "unpoisoned" (returned to the free pool). 3. **Root Cause**: When a page is isolated (e.g., during memory error handling or testing), its allocation tags are modified or accounted for. However, when the page is returned to the free list (`free_unref_page`), the code fails to **clear or reset the page tag reference** properly. This leads to an inconsistency in the tag accounting subsystem, causing a panic or oops when `pgalloc_tag_sub` tries to update the tag counters for a page that is no longer in a valid state for such accounting.
### The Fix
As suggested in the prompt, the fix is to **clear the page tag reference after the page has been isolated and accounted for**, before it is returned to the free pool.
In the Linux kernel source, this typically involves modifying the `unpoison_memory` function or the related page isolation logic in `mm/memory-failure.c` or `mm/page_alloc.c`.
#### Likely Code Change
The fix should ensure that when a page is unpoisoned and put back, its allocation tags are cleared or reset to avoid double-accounting or invalid state.
Here is a conceptual patch based on the description:
```c // In mm/memory-failure.c or similar file
static int unpoison_memory(unsigned long pfn) {
struct page *page = pfn_to_page(pfn); int ret;
// ... existing code to isolate and check the page ...
// After isolating the page and accounting for it, // clear the page tag reference to prevent issues in pgalloc_tag_sub // when the page is later freed.
// Example: Clear the page tag if the kernel is compiled with // CONFIG_PAGE_ALLOC_TAGGING or similar debugging options. if (PagePoisoned(page)) {
// Clear the poisoned flag ClearPagePoison(page); // Clear the page tag reference to reset accounting state // This is the key fix mentioned in the prompt clear_page_tag(page); // Pseudocode for the actual kernel function }
// ... rest of the unpoison logic ... return ret; } ```
### Specific Kernel Fix (If applicable to a known CVE or patch)
If this is related to a specific known issue (e.g., in kernels around 6.1-6.6), the fix might look like this in `mm/memory-failure.c`:
```c // After isolating the page and before returning it to the free list if (PageHWPoison(page)) {
ClearPageHWPoison(page); // Clear the page tag to avoid accounting errors in pgalloc_tag_sub page_tag_clear(page); } ```
### Summary
- **Problem**: Page allocation tag accounting fails when a poisoned page is unpoisoned and freed because the tag reference is not cleared. - **Solution**: Clear the page tag reference after isolation and accounting, before the page is returned to the free pool. - **Affected Components**: `mm/memory-failure.c`, `mm/page_alloc.c`, and the page allocation tagging subsystem.
This fix ensures that the page's state is fully reset when it is unpoisoned, preventing inconsistencies in the debugging/tracking subsystems.
If you want to get best quality of vulnerability data, you may have to visit VulDB.