linux-kernel - Re: [PATCH] block: loop: fix filesystem corruption in case of aio/dio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <5710F18E.7060700@googlemail.com>
Date:	Fri, 15 Apr 2016 15:50:06 +0200
From:	Holger Hoffstätte 
	<holger.hoffstaette@...glemail.com>
To:	Ming Lei <ming.lei@...onical.com>, Jens Axboe <axboe@...com>,
	linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
	stable@...r.kernel.org
Cc:	Christoph Hellwig <hch@...radead.org>,
	Keith Busch <keith.busch@...el.com>
Subject: Re: [PATCH] block: loop: fix filesystem corruption in case of aio/dio

-------- Forwarded Message --------
Subject: Re: [PATCH] block: loop: fix filesystem corruption in case of aio/dio
Date: Fri, 15 Apr 2016 21:16:42 +0800
From: Ming Lei <ming.lei@...onical.com>
To: Holger Hoffstätte <holger.hoffstaette@...glemail.com>

On Fri, Apr 15, 2016 at 8:51 PM, Holger Hoffstätte
<holger.hoffstaette@...glemail.com> wrote:
> (off-list since I'm likely missing something..)
>
> Hello Ming Lei,
>
> quick question -
>
> On 04/15/16 12:51, Ming Lei wrote:
>> Starting from commit e36f620428(block: split bios to max possible length),
>> block core starts to split bio in the middle of bvec.
>>
>> Unfortunately loop dio/aio doesn't consider this situation, and
>> always treat 'iter.iov_offset' as zero. Then filesystem corruption
>> is observed.
>>
>> This patch figures out the offset of the base bvevc via
>> 'bio->bi_iter.bi_bvec_done' and fixes the issue by passing the offset
>> to iov iterator.
>>
>> Fixes: e36f6204288088f (block: split bios to max possible length)
>> Cc: Keith Busch <keith.busch@...el.com>
>> Cc: Al Viro <viro@...iv.linux.org.uk>
>> Cc: stable@...r.kernel.org (4.5)
>                              ^^^^^
>
> The previous patch went into 4.4.x-stable, so should this one not go
> into 4.4.x as well? It applies cleanly and does not seem to hurt.
> Apologies in advance if this is a bad idea. :)

You are absolutely right, this patch should have been marked as stable 4.4+,
thanks for point it out!

Jens, please let me know if you need me to resend the patch for fixing
the stable tag.

Thanks,
Ming