Messages in this thread | | | From | Cong Wang <> | Date | Tue, 13 Dec 2016 15:56:02 -0800 | Subject | Re: CVE-2016-7097 causes acl leak |
| |
On Tue, Dec 13, 2016 at 3:28 AM, Jan Kara <jack@suse.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@android.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.
| |