Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 13 Aug 2018 09:24:18 +0900
From:   Seung-Woo Kim <sw0312.kim@samsung.com>
Reply-To: sw0312.kim@samsung.com
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011
        Thunderbird/16.0.1
MIME-Version: 1.0
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC:     Al Viro <viro@ZenIV.linux.org.uk>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        stable <stable@vger.kernel.org>, lwn@lwn.net,
        Jiri Slaby <jslaby@suse.cz>,
        Seung-Woo Kim <sw0312.kim@samsung.com>
Subject: Re: Linux 3.18.111
In-Reply-To: <20180810101158.GA31002@kroah.com>
Content-Transfer-Encoding: 8bit
Message-Id: <20180813002409epcas1p2d0c7cf768c533de9348a994e614fc6ea~KSd-6p8Bi1658316583epcas1p2a@epcas1p2.samsung.com>
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 101P
DLP-Filter: Pass
References: <CGME20180530073304epcas3p4967df82d2d086fd08fd354781df61861@epcas3p4.samsung.com>
        <20180530073211.GA22422@kroah.com>
        <20180703032456epcas1p29c4570ae3f6bb3f8d7c2d475e1ba4658~9vfIpgNT51989519895epcas1p2d@epcas1p2.samsung.com>
        <20180703043655.GA9793@kroah.com>
        <20180703044302epcas1p4ff5961129c010a2df3548cf678b6274c~9wjUy-vFW2959129591epcas1p4p@epcas1p4.samsung.com>
        <CA+55aFz-K8s-Sh86PqxRaXTD5pG=YsVUCxf9ue8XOSaGmg-brw@mail.gmail.com>
        <20180705005205.GC30522@ZenIV.linux.org.uk>
        <20180808100622epcas1p1d4e3d6f858a9de3014f6d79bf284ff2c~I4L612J9p0428204282epcas1p1X@epcas1p1.samsung.com>
        <20180810064258epcas1p3eb68d29dbd60b705d0473b3c645496ff~Jcs48Q55D0165001650epcas1p3e@epcas1p3.samsung.com>
        <20180810101158.GA31002@kroah.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 2018년 08월 10일 19:11, Greg Kroah-Hartman wrote:
> On Fri, Aug 10, 2018 at 03:43:02PM +0900, Seung-Woo Kim wrote:
>> On 2018년 08월 08일 19:06, Seung-Woo Kim wrote:
>>> On 2018년 07월 05일 09:52, Al Viro wrote:
>>>> On Mon, Jul 02, 2018 at 10:01:25PM -0700, Linus Torvalds wrote:
>>>>> On Mon, Jul 2, 2018 at 9:43 PM Seung-Woo Kim <sw0312.kim@samsung.com> wrote:
>>>>>>
>>>>>> I think the commit itself is required. Simple, but not reliable,
>>>>>> workaround fix is like below:
>>>>>>
>>>>>> diff --git a/fs/dcache.c b/fs/dcache.c
>>>>>> index a34d401..7c751f2 100644
>>>>>> --- a/fs/dcache.c
>>>>>> +++ b/fs/dcache.c
>>>>>> @@ -1879,6 +1879,8 @@ void d_instantiate_new(struct dentry *entry,
>>>>>> struct inode *inode)
>>>>>>         BUG_ON(!hlist_unhashed(&entry->d_u.d_alias));
>>>>>>         BUG_ON(!inode);
>>>>>>         lockdep_annotate_inode_mutex_key(inode);
>>>>>> +       /* WORKAROUND for calling security_d_instantiate() */
>>>>>> +       entry->d_inode = inode;
>>>>>>         security_d_instantiate(entry, inode);
>>>>>>         spin_lock(&inode->i_lock);
>>>>>>         __d_instantiate(entry, inode);
>>>>>
>>>>> Ugh. That looks horrible even if it might avoid the oops.
>>>>>
>>>>> I think a much better solution is to back-port commit b296821a7c42
>>>>> ("xattr_handler: pass dentry and inode as separate arguments of
>>>>> ->get()") to older kernels. Then the inode is passed down all the way,
>>>>> and you don't have people try to get it from the (not yet initialized)
>>>>> dentry.
>>>>>
>>>>> But there might be other parts missing too, and I didn't look at how
>>>>> easy/painful that backport would be.
>>>>>
>>>>> Al - comments? This is all because of commit 1e2e547a93a0 ("do
>>>>> d_instantiate/unlock_new_inode combinations safely") being marked for
>>>>> stable, and various cases of security_d_instantiate() calling down to
>>>>> getxattr. Which used to not get the inode at all, so those older
>>>>> kernels use d_inode(dentry), which doesn't work in this path since
>>>>> dentry->d_inode hasn't been instantiated yet..
>>>>
>>>> You also want b96809173e94 and ce23e6401334 there...
>>>
>>> For above two commits, also b296821a7c42 is required. And after
>>> backport, smack still crashed because setxattr. To fix it, 5930122683df
>>> and 3767e255b390 are also required.
>>>
>>> By the way, does no one have met this kind getxattr crash issue with
>>> selinux from 3.18.y?
>>>
>>
>> I have checked with selinux, and it is confirmed that there is no crash
>> because selinux_d_instantiate() has null check for inode. So, it is only
>> security smack issue.
> 
> So are the 5 patches you sent ok to apply to the 3.18-stable tree?  Or
> do we need to do something else?
> 

Those 5 patches are fine in my smack environment. I have not tested all
the file systems in run-time except ext2/4 and I only tested build for
those file systems.

Best Regards,
- Seung-Woo Kim

> thanks,
> 
> greg k-h
> 
>