Hi Andrii,

On Mon, May 18, 2026 at 05:32:33PM +0300, Andrii Kuchmenko wrote:

module_extend_max_pages() calls kvrealloc() internally and returns
-ENOMEM on allocation failure. The return value is never checked.

We should definitely fix this, but I'm not sure the rest of the
commit message is entirely accurate.

The decompression loop then continues calling module_get_next_page(),
which writes struct page pointers into info->pages[]. When used_pages
reaches the stale max_pages value (not updated due to the failed
extend), a subsequent write to info->pages[used_pages++] goes out of
bounds into adjacent heap memory.

Adjacent slab objects in the same kmalloc cache (pipe_buffer,
seq_operations, cred) can be corrupted, potentially leading to local
privilege escalation on kernels without SLAB_VIRTUAL mitigation.

Looking at the code:

- struct load_info info is zero-initialized in init_module_from_file().

- If module_extend_max_pages() fails, info->pages remains NULL and
  info->max_pages and info->used_pages both remain 0.

- module_get_next_page() sees info->max_pages == info->used_pages
  immediately and calls module_extend_max_pages(info, 0).

- kvrealloc() is called with a size of 0 and it returns ZERO_SIZE_PTR.

- Because ZERO_SIZE_PTR != NULL, module_extend_max_pages() sets
  info->pages to ZERO_SIZE_PTR and returns 0.

- module_get_next_page() writes to info->pages[info->used_pages++],
  and the write to ZERO_SIZE_PTR results in an immediate oops.

This isn't great, but I do not see a potential for an out-of-bounds
write or slab corruption in this specific case. What am I missing?

Sami