On Mon, 17 Apr 2023, Matthew Wilcox wrote:
> On Mon, Apr 17, 2023 at 03:11:57PM -0400, Mikulas Patocka wrote:
> > If we use bio_for_each_folio_all on an empty bio, it will access the first
> > bio vector unconditionally (it is uninitialized) and it may crash
> > depending on the uninitialized data.
>
> Wait, how do we have an empty bio in the first place?
dm-crypt (with the patch that you suggested here:
https://www.spinics.net/lists/kernel/msg4691572.html
https://lore.kernel.org/linux-mm/alpine.lrh.2.21.2302161619430.5...@file01.intranet.prod.int.rdu2.redhat.com/T/
) calls:
gfp_t gfp_mask = GFP_NOWAIT | __GFP_HIGHMEM;
...
pages = mempool_alloc(&cc->page_pool, gfp_mask);
if (!pages) {
crypt_free_buffer_pages(cc, clone);
bio_put(clone);
gfp_mask |= __GFP_DIRECT_RECLAIM;
order = 0;
goto retry;
}
If the mempool_alloc of the first page fails (it may happen because it
uses GFP_NOWAIT), crypt_free_buffer_pages will be called with an empty
bio.
I also hit this bug when fixing a dm-flakey target - it is triggered by
this:
https://people.redhat.com/~mpatocka/patches/kernel/dm-flakey/dm-flakey-02-clone-pages.patch
I think that this patch doesn't have to be backported to the stable
kernels (because there is currently no user that calls
bio_for_each_folio_all on an empty bio), but for the next merge window,
dm-crypt and dm-flakey is going to use it.
Mikulas
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
