Executive brief
The Linux kernel's memory allocation tracking feature (/proc/allocinfo) has a use-after-free vulnerability in its iterator logic. When a kernel module is unloaded while the allocinfo interface is being read in multiple batches, freed module memory can still be accessed, potentially causing system crashes or undefined behavior. This vulnerability affects systems that dynamically load and unload kernel modules while monitoring memory allocations.
Technical details
The vulnerability is a use-after-free in lib/alloc_tag.c affecting the allocinfo_start() and allocinfo_stop() functions. The root cause is that allocinfo_start() only reinitializes the codetag iterator at position 0; for subsequent reads (position > 0), it reuses cached iterator state from the previous read batch. Between read batches, allocinfo_stop() releases mod_lock, allowing a module unload (rmmod) on another CPU to proceed, free module memory including the module's .rodata section, and complete before allocinfo_start() is called again. The iterator then dereferences freed pointers (ct->filename, ct->function) in allocinfo_show(). The fix saves iterator state in allocinfo_next() and resumes from it in allocinfo_start() with proper module removal detection via idr_find(). Exploitation requires specific timing: concurrent /proc/allocinfo reading and module unload. A patch is available in upstream kernel commits 2956268efc457cb05d29c1bf94de1e8e684d7bbc (mainline) and 008ceffd44040f809aead6d7bef7cb1210c4149a (stable).
Affected products
- Linux Linux kernel Linux 5.15 and later (when alloc_tag feature is enabled)
Timeline
- 2026-08-15: disclosed
- 2026-06-04: patched