[Top] [All Lists]

Re: [PATCH] xfsprogs: fix use after free in inode_item_done()

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxx>
Subject: Re: [PATCH] xfsprogs: fix use after free in inode_item_done()
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Wed, 05 Mar 2014 11:19:19 -0600
Cc: xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140305170256.GB11667@xxxxxxxxxxxxx>
References: <5314E912.9080708@xxxxxxxxxx> <20140305170256.GB11667@xxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
On 3/5/14, 11:02 AM, Christoph Hellwig wrote:
> On Mon, Mar 03, 2014 at 02:41:54PM -0600, Eric Sandeen wrote:
>> Commit "3a19fb7 libxfs: stop caching inode structures"
>> introduced a use after free.
> I see the use after free, but I don't see how I would have introduced it
> in that commit.  Before that libxfs_iput already was freeing the inode
> through the cache code, now we do it directly.

Ok, sorry if I wrongly implicated that commit.

>> @@ -739,12 +738,6 @@ ili_done:
>>      } else {
>>              libxfs_iput(ip, 0);
>>      }
>> -
>> -    if (ip->i_itemp)
>> -            kmem_zone_free(xfs_ili_zone, ip->i_itemp);
>> -    else
>> -            ASSERT(0);
>> -    ip->i_itemp = NULL;
>>  }
> Seems like inode_item_done should call into inode_item_unlock, which
> factors the exact sequence we want into a nice helper.

Yeah, that does seem better!   Thanks for spotting that.

The difference when calling inode_item_unlock is a bit more zeroing-out:

        ip->i_transp = NULL;

        iip->ili_flags = 0;

I'm not sure of the implications of that offhand, TBH.

Dave, hold off on my commit I guess ;)


<Prev in Thread] Current Thread [Next in Thread>