Re: Linux 3.18.111

From: Greg KH <gregkh@linuxfoundation.org>
To: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	torvalds@linux-foundation.org, stable@vger.kernel.org,
	lwn@lwn.net, Jiri Slaby <jslaby@suse.cz>
Subject: Re: Linux 3.18.111
Date: Tue, 3 Jul 2018 06:36:55 +0200	[thread overview]
Message-ID: <20180703043655.GA9793@kroah.com> (raw)
In-Reply-To: <20180703032456epcas1p29c4570ae3f6bb3f8d7c2d475e1ba4658~9vfIpgNT51989519895epcas1p2d@epcas1p2.samsung.com>

On Tue, Jul 03, 2018 at 12:24:59PM +0900, Seung-Woo Kim wrote:
> Hello,
> 
> On 2018년 05월 30일 16:32, Greg KH wrote:
> > I'm announcing the release of the 3.18.111 kernel.
> > 
> > All users of the 3.18 kernel series must upgrade.
> > 
> > The updated 3.18.y git tree can be found at:
> > 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y
> > and can be browsed at the normal kernel.org git web browser:
> > 	http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
> > 
> > thanks,
> > 
> > greg k-h
> > 
> > ------------
> 
> <snip.>
> 
> >       do d_instantiate/unlock_new_inode combinations safely
> 
> Recent my test in 3.18.113 kernel with security smack showed following
> crash during mkdir on ext4 fs.
> 
> Unable to handle kernel paging request at virtual address ffffffffffffff98
> pgd = ffffffc012411000
> [ffffffffffffff98] *pgd=0000000000000000, *pud=0000000000000000
> ------------[ cut here ]------------
> Kernel BUG at ffffffc0007d9430 [verbose debug info unavailable]
> Internal error: Oops - BUG: 96000005 [#1] PREEMPT SMP
> CPU: 0 MPIDR: 80000000 PID: 1237 Comm: mkdir Not tainted
> 3.18.113-00083-g1bfc02f-dirty #29-Tizen
> task: ffffffc02cbc2340 ti: ffffffc02b7fc000 task.ti: ffffffc02b7fc000
> PC is at down_read+0x24/0x54
> LR is at down_read+0x24/0x54
> [...]
> Call trace:
> [<ffffffc0007d9430>] down_read+0x24/0x54
> [<ffffffc00022ff64>] ext4_xattr_get+0x74/0x1f4
> [<ffffffc000234838>] ext4_xattr_security_get+0x28/0x38
> [<ffffffc0001ab9f0>] generic_getxattr+0x4c/0x60
> [<ffffffc0002786a0>] smk_fetch.isra.6+0x8c/0xe0
> [<ffffffc000278888>] smack_d_instantiate+0x194/0x324
> [<ffffffc000273794>] security_d_instantiate+0x24/0x30
> [<ffffffc00019edf4>] d_instantiate_new+0x34/0x94
> [<ffffffc0002046b4>] ext4_mkdir+0x284/0x354
> [<ffffffc0001959bc>] vfs_mkdir+0xc0/0x150
> [<ffffffc00019a108>] SyS_mkdirat+0x88/0xb8
> [<ffffffc00019a150>] SyS_mkdir+0x18/0x20
> Code: aa0003f3 b00017c0 912e1000 97e38943 (c85f7e60)
> ---[ end trace b1ad797d63dae9c5 ]---
> 
> It is because d_instantiate_new() added from above commit calls
> security_d_instantiate() before calling __d_instantiate() and
> dentry->d_inode is not yet set and null. In 3.18.113 kernel,
> inode->i_op_getxattr() of ext4 is still generic_getxattr() and it only
> has dentry parameter without inode, so it tries to access dentry->d_inode.
> 
> I did not test with selinux, but selinux also calls
> inode->i_op_getxattr() from selinux_d_instantiate(), so maybe there is
> also same issue.

So should I revert something or do you have a proposed fix for this?

thanks,

greg k-h