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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 19 Apr 2020 00:42:24 -0400
From:   "Theodore Y. Ts'o" <>
To:     Ritesh Harjani <>
Cc:     Murphy Zhou <>,
        Ext4 Developers List <>
Subject: Re: [PATCH] ext4: validate fiemap iomap begin offset and length value

On Sun, Apr 19, 2020 at 07:26:53AM +0530, Ritesh Harjani wrote:
> ++ mailing list.
> Sorry somehow it got dropped.
> On 4/19/20 7:21 AM, Ritesh Harjani wrote:
> > Hello Murphy,
> > 
> > I guess the patch to fix this issue was recently submitted.
> > Could you please test your reproducer, xfstest and ltp
> > tests on below patch too. And let me know if we can add your Tested-by:
> > 
> >

His reproducer is still failing with your patch.  In order to for his
reproducer to succeed, we need to constrain lblk and last_lblk more
strictly than what is done in:

[PATCHv2 1/1] ext4: fix overflow case for map.m_len in ext4_iomap_begin_*

His patch does fix the issue.

ext4_map_block() is returning EFSCORRUPTED when lblk is
EXT4_MAX_LOGICAL_BLOCK, which is why he's constraining lblk to
EXT4_MAX_LOGICAL_BLOCK.  I haven't looked into this more closely yet,
but it looks we have some overflow/wraparound issue when lblk is
0xFFFFFFFF.  Which might mean that in fact EXT4_MAX_LOGICAL_BLOCK
might need to be 0xFFFFFFFE, or we need to look very closely our code
paths to make sure the right thing happes when we call
ext4_map_blocks() with m_lblk == 0xFFFFFFFF and m_len == 1.

I think we need to take his patch, and make a simialr change to
ext4_iomap_begin().   Ritesh, do you agree?

						- Ted

Powered by blists - more mailing lists