| Message ID | alpine.LRH.2.21.2301221402130.15312@file01.intranet.prod.int.rdu2.redhat.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Delegated to: | Mike Snitzer |
| Headers | show |
| Series | [1/3] dm-flakey: don't corrupt the zero page | expand |
On 1/22/23 14:02, Mikulas Patocka wrote: > When we need to zero some range on a block device, the function > __blkdev_issue_zero_pages submits a write bio with the bio vector pointing > to the zero page. If we use dm-flakey with corrupt bio writes option, it > will corrupt the content of the zero page which results in crashes of > various userspace programs. Glibc assumes that memory returned by mmap is > zeroed and it uses it for calloc implementation; if the newly mapped > memory is not zeroed, calloc will return non-zeroed memory. > > This patches fixes the bug by testing if the page is equal to ZERO_PAGE(0) > and avoiding the corruption in this case. Nice catch! > > Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> > Cc: stable@vger.kernel.org Reviewed-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me> > > --- > drivers/md/dm-flakey.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > Index: bcachefs/drivers/md/dm-flakey.c > =================================================================== > --- bcachefs.orig/drivers/md/dm-flakey.c 2023-01-22 16:56:35.000000000 +0100 > +++ bcachefs/drivers/md/dm-flakey.c 2023-01-22 16:58:40.000000000 +0100 > @@ -303,8 +303,11 @@ static void corrupt_bio_data(struct bio > */ > bio_for_each_segment(bvec, bio, iter) { > if (bio_iter_len(bio, iter) > corrupt_bio_byte) { > - char *segment = (page_address(bio_iter_page(bio, iter)) > - + bio_iter_offset(bio, iter)); > + char *segment; > + struct page *page = bio_iter_page(bio, iter); > + if (unlikely(page == ZERO_PAGE(0))) > + break; > + segment = (page_address(page) + bio_iter_offset(bio, iter)); > segment[corrupt_bio_byte] = fc->corrupt_bio_value; > DMDEBUG("Corrupting data bio=%p by writing %u to byte %u " > "(rw=%c bi_opf=%u bi_sector=%llu size=%u)\n", > -- > dm-devel mailing list > dm-devel@redhat.com > https://listman.redhat.com/mailman/listinfo/dm-devel -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
Index: bcachefs/drivers/md/dm-flakey.c =================================================================== --- bcachefs.orig/drivers/md/dm-flakey.c 2023-01-22 16:56:35.000000000 +0100 +++ bcachefs/drivers/md/dm-flakey.c 2023-01-22 16:58:40.000000000 +0100 @@ -303,8 +303,11 @@ static void corrupt_bio_data(struct bio */ bio_for_each_segment(bvec, bio, iter) { if (bio_iter_len(bio, iter) > corrupt_bio_byte) { - char *segment = (page_address(bio_iter_page(bio, iter)) - + bio_iter_offset(bio, iter)); + char *segment; + struct page *page = bio_iter_page(bio, iter); + if (unlikely(page == ZERO_PAGE(0))) + break; + segment = (page_address(page) + bio_iter_offset(bio, iter)); segment[corrupt_bio_byte] = fc->corrupt_bio_value; DMDEBUG("Corrupting data bio=%p by writing %u to byte %u " "(rw=%c bi_opf=%u bi_sector=%llu size=%u)\n",
When we need to zero some range on a block device, the function __blkdev_issue_zero_pages submits a write bio with the bio vector pointing to the zero page. If we use dm-flakey with corrupt bio writes option, it will corrupt the content of the zero page which results in crashes of various userspace programs. Glibc assumes that memory returned by mmap is zeroed and it uses it for calloc implementation; if the newly mapped memory is not zeroed, calloc will return non-zeroed memory. This patches fixes the bug by testing if the page is equal to ZERO_PAGE(0) and avoiding the corruption in this case. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org --- drivers/md/dm-flakey.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel