linux-kernel - Re: CVE-2016-7097 causes acl leak

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAM_iQpXUpgDMkFRA5Mg_cnda0fe94HdjNxmjykDwKw-y-d63=A@mail.gmail.com>
Date:   Tue, 13 Dec 2016 15:56:02 -0800
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Jan Kara <jack@...e.cz>
Cc:     Mark Salyzyn <salyzyn@...roid.com>,
        LKML <linux-kernel@...r.kernel.org>,
        aneesh.kumar@...ux.vnet.ibm.com
Subject: Re: CVE-2016-7097 causes acl leak

On Tue, Dec 13, 2016 at 3:28 AM, Jan Kara <jack@...e.cz> wrote:
> On Mon 12-12-16 22:26:09, Cong Wang wrote:
>> On Mon, Dec 12, 2016 at 4:26 PM, Mark Salyzyn <salyzyn@...roid.com> wrote:
>> >
>> > The leaks were introduced in 9p, gfs2, jfs and xfs drivers only.
>>
>>
>> Only the 9p case is obvious to me:
>
> Agreed and the patch below looks good to me. Please make it a proper patch
> (including changelog, sign-off, etc.) and feel free to add my Reviewed-by
> tag.

Done.


>> The rest are anti-pattern (modifying parameters on stack via address)
>> but look correct.
>
> I'm not sure what's so unusual about passing a pointer to a local variable
> (in fact a function argument but they are no different in C) to another
> function. I agree it is not the most straightforward code but it is not that
> complicated either...

Function arguments technically belong to caller's context, while local
variables belong to callee's. I have never seen such a use case in kernel
code base, this is why I think it is anti-pattern.

>
> What is important is that a function that acquires a reference to an acl also
> releases that reference. That is a common pattern. I.e. we don't pass "a
> reference to an object", we just pass "a pointer to an object" to a
> function and guarantee the pointer will stay valid while the function runs.
> What does some function (in our case ->set_acl handler) do with the pointer
> you passed it is it's internal bussiness.
>

But passing a pointer to a pointer usually indicates we need to save
the pointer,
in this case we actually don't, it is discarded as soon as the caller returns.

Thanks.