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.5436@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/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@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
