Re: [PATCH v2] module: decompress: check return value of module_extend_max_pages()

[Sami Tolvanen <samitolvanen@google.com>]

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