linux-kernel - Re: [PATCH v2] z3fold: fix the potential encode bug in encod

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <580580AE.6070200@huawei.com>
Date:   Tue, 18 Oct 2016 09:53:50 +0800
From:   zhong jiang <zhongjiang@...wei.com>
To:     Dan Streetman <ddstreet@...e.org>
CC:     Vitaly Wool <vitalywool@...il.com>,
        Dave Chinner <david@...morbit.com>,
        Seth Jennings <sjenning@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...nel.org>,
        "Vlastimil Babka" <vbabka@...e.cz>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>
Subject: Re: [PATCH v2] z3fold: fix the potential encode bug in encod_handle

On 2016/10/17 23:30, Dan Streetman wrote:
> On Mon, Oct 17, 2016 at 8:48 AM, zhong jiang <zhongjiang@...wei.com> wrote:
>> On 2016/10/17 20:03, Vitaly Wool wrote:
>>> Hi Zhong Jiang,
>>>
>>> On Mon, Oct 17, 2016 at 3:58 AM, zhong jiang <zhongjiang@...wei.com> wrote:
>>>> Hi,  Vitaly
>>>>
>>>> About the following patch,  is it right?
>>>>
>>>> Thanks
>>>> zhongjiang
>>>> On 2016/10/13 12:02, zhongjiang wrote:
>>>>> From: zhong jiang <zhongjiang@...wei.com>
>>>>>
>>>>> At present, zhdr->first_num plus bud can exceed the BUDDY_MASK
>>>>> in encode_handle, it will lead to the the caller handle_to_buddy
>>>>> return the error value.
>>>>>
>>>>> The patch fix the issue by changing the BUDDY_MASK to PAGE_MASK,
>>>>> it will be consistent with handle_to_z3fold_header. At the same time,
>>>>> change the BUDDY_MASK to PAGE_MASK in handle_to_buddy is better.
>>> are you seeing problems with the existing code? first_num should wrap around
>>> BUDDY_MASK and this should be ok because it is way bigger than the number
>>> of buddies.
>>>
>>> ~vitaly
>>>
>>> .
>>>
>>  first_num plus buddies can exceed the BUDDY_MASK. is it right?
> yes.
>
>>  (first_num + buddies) & BUDDY_MASK may be a smaller value than first_num.
> yes, but that doesn't matter; the value stored in the handle is never
> accessed directly.
>
>>   but (handle - zhdr->first_num) & BUDDY_MASK will return incorrect value
>>   in handle_to_buddy.
> the subtraction and masking will result in the correct buddy number,
> even if (handle & BUDDY_MASK) < zhdr->first_num.
 yes, I see. it is hard to read.
> However, I agree it's nonobvious, and tying the first_num size to
> NCHUNKS_ORDER is confusing - the number of chunks is completely
> unrelated to the number of buddies.
 yes. indeed.
> Possibly a better way to handle first_num is to limit it to the order
> of enum buddy to the actual range of possible buddy indexes, which is
> 0x3, i.e.:
>
> #define BUDDY_MASK      (0x3)
>
> and
>
>        unsigned short first_num:2;
>
> with that and a small bit of explanation in the encode_handle or
> handle_to_buddy comments, it should be clear how the first_num and
> buddy numbering work, including that overflow/underflow are ok (due to
> the masking)...
 yes, It is better and clearer. Thanks for your relpy and advice. I will
 resend the patch.
>>   Thanks
>>   zhongjiang
>>
>>
> .
>