CVE-2023-53621 in Linux
Zusammenfassung
von VulDB • 18.05.2026
Based on the stack trace and the partial commit message provided, here is an analysis of the issue and the likely fix.
### Analysis of the Stack Trace
1. **Context**: The crash occurs in `filemap_add_folio`, which is part of the Linux kernel's page cache management. It is triggered by a `pread64` system call (`__x64_sys_pread64`), meaning a user-space process is reading from a file. 2. **Call Chain**: * `filemap_read`: Initiates the read operation. * `page_cache_sync_ra`: Performs synchronous read-ahead. * `page_cache_ra_unbounded`: Unbounded read-ahead logic. * `filemap_add_folio`: Attempts to add a newly allocated folio (page) to the page cache. 3. **The Problem**: The crash happens during `filemap_add_folio`. This function typically involves accounting for memory usage, particularly in the context of **Memory Control Groups (memcg)**. The stack trace shows `filemap_add_folio+0x4d/0x70`, suggesting the crash is near the beginning of this function, likely during the accounting or ID publication step.
### The Fix
The commit message snippet states: > "This patch fixes the issue by moving the memcg's id publication from the alloc stage to ..."
This indicates that the bug was related to **Memory Cgroup (memcg) accounting** during page allocation. Specifically:
* **Root Cause**: The kernel was publishing (making visible) the memcg ID associated with a newly allocated page *too early*—during the allocation stage (`alloc stage`). This could lead to a race condition or use-after-free scenario if the page was not yet fully initialized or if the memcg context was not yet stable. * **Solution**: The fix moves the publication of the memcg ID to a later stage, likely **after** the folio is fully added to the page cache or after the accounting is safely established. This ensures that the memcg ID is only visible when the page is in a consistent and safe state for accounting purposes.
### Likely Commit Details
This issue is consistent with fixes in the Linux kernel related to **memcg page accounting** and **folio allocation**. A known class of bugs involves the `folio->memcg` pointer or ID being accessed before it is properly set or after it is freed.
The specific fix likely involves: 1. Delaying the call to `folio_memcg()` or similar accounting functions. 2. Ensuring that the memcg ID is only published after `filemap_add_folio` has successfully integrated the folio into the page cache.
### Conclusion
The patch fixes a **race condition or use-after-free bug in memory cgroup accounting** during file read-ahead operations. By deferring the publication of the memcg ID until after the folio is safely added to the page cache, the kernel avoids accessing invalid or uninitialized memcg data, preventing the crash in `filemap_add_folio`.
If you need the exact commit hash or more details, you can search the Linux kernel git log for keywords like: * `filemap_add_folio memcg` * `page_cache_ra_unbounded memcg id` * `folio memcg publication`
This type of fix is common in kernels where memory accounting is tightly integrated with page cache operations, especially in versions where memcg v2 accounting was being refined.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.