On Thu, 2023-07-20 at 08:00 +0300, Mike Rapoport wrote: > Hi Ric, > > On Wed, Jul 19, 2023 at 03:41:37PM -0400, Rik van Riel wrote: > > The memblock_discard function frees the memblock.reserved.regions > > array, which is good. > > > > However, if a subsequent memblock_free (or memblock_phys_free) > > comes > > in later, from for example ima_free_kexec_buffer, that will result > > in > > a use after free bug in memblock_isolate_range. > > The use of memblock_phys_free() in ima_free_kexec_buffer() is > entirely > bogus and must be fixed. It should be memblock_free_late() there. > I'll send in a patch for that code, then. Thank you! > > When running a kernel with CONFIG_KASAN enabled, this will cause a > > kernel panic very early in boot. Without CONFIG_KASAN, there is > > a chance that memblock_isolate_range might scribble on memory > > that is now in use by somebody else. > > This can't happen because memblock_double_array() uses kmalloc() as > soon as > slab_is_available(), so this sentence is misleading. memblock_discard() freed the array, but did not change the pointer. That resulted in memblock_isolate_range() following a stale pointer. There was no call to memblock_double_array() in the final call that crashed. I checked that by booting with memblock=debug. kind regards, Rik van Riel -- All Rights Reversed.
Attachment:
signature.asc
Description: This is a digitally signed message part
