[Xenial][Bionic][SRU][PATCH 0/1] cap_inode_getsecurity: use d_find_any_alias() instead of d_find_alias()

Po-Hsu Lin po-hsu.lin at canonical.com
Wed Oct 24 06:54:48 UTC 2018


BugLink: https://bugs.launchpad.net/bugs/1786729

== Justification ==
The code in cap_inode_getsecurity(), introduced by commit 8db6c34f1dbc
("Introduce v3 namespaced file capabilities"), should use
d_find_any_alias() instead of d_find_alias() do handle unhashed dentry
correctly. This is needed, for example, if execveat() is called with an
open but unlinked overlayfs file, because overlayfs unhashes dentry on
unlink.
This is a regression of real life application, first reported at
https://www.spinics.net/lists/linux-unionfs/msg05363.html

With the execveat03 test in the LTP test suite on an affected kernel, it will fail with:
<<<test_start>>>
tag=execveat03 stime=1534135632
cmdline="execveat03"
contacts=""
analysis=exit
<<<test_output>>>
incrementing stop
tst_test.c:1017: INFO: Timeout per run is 0h 05m 00s
execveat03.c:70: FAIL: execveat() returned unexpected errno: EINVAL

Summary:
passed 0
failed 1
skipped 0
warnings 0

== Fix ==
355139a8 (cap_inode_getsecurity: use d_find_any_alias() instead of
 d_find_alias())

It can be cherry-picked for Bionic, but it needs to be backported to Xenial along with the logic when we backport 8db6c34f1dbc (bug 1778286).

The test kernel for Xenial / Bionic could be found here:
http://people.canonical.com/~phlin/kernel/lp-1786729-execveat03/

This patch has already been cherry-picked into Cosmic and Unstable.

== Regression Potential ==
Low, this patch just uses a correct function to handle unhashed dentry, and it's been applied in both upstream and our newer kernel.

== Test Case ==
Run the reproducer in the commit message, or,
run the execveat03 test in ubuntu_ltp_syscalls test suite. And it will pass with the patched kernel.



Eddie.Horng (1):
  cap_inode_getsecurity: use d_find_any_alias() instead of
    d_find_alias()

 security/commoncap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.7.4





More information about the kernel-team mailing list