VERIFY BUG ON XENIAL #Test with latest kernel in -updates
$ uname -a Linux xenial-kernel 4.4.0-173-generic #203-Ubuntu SMP Wed Jan 15 02:55:01 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $./make-overlay.sh $ ./test.sh st_mode is 100644 open failed: -1 cat: /tmp/overlay/animal: Permission denied -rw-r--r-- 1 jo jo 0 Jan 31 16:54 /tmp/overlay/animal Issue is reproducible. #Test with kernel in -proposed $ uname -a Linux xenial-kernel 4.4.0-174-generic #204-Ubuntu SMP Wed Jan 29 06:41:01 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $./make-overlay.sh $ ./test.sh st_mode is 100644 -rw-r--r-- 1 jo jo 0 Jan 31 16:59 /tmp/overlay/animal Issue has been resolved. ** Tags removed: verification-needed-xenial ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1851243 Title: overlayfs : broken access to r/w files Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: Fix Committed Bug description: [Description] Commit c0ca3d70e8d3(ovl: modify ovl_permission() to do checks on two inodes) (upstream id) breaks r/w access in overlayfs in 4.4 ubuntu kernels, later ubuntu kernels are not affected. There are two options to fix this either (a) backport ce31513a9114(ovl: copyattr after setting POSIX ACL) to 4.4 or (b) revert offending commit c0ca3d70e8d3(ovl: modify ovl_permission() to do checks on two inodes). Option (a) has high risk of regression since ce31513a9114(ovl: copyattr after setting POSIX ACL) has many dependencies on other commits that need to be backported too. We'll proceed with reverting c0ca3d70e8d3(ovl: modify ovl_permission() to do checks on two inodes). This commit is associated with CVE-2018-16597, however 4.4 kernels (both ubuntu and upstream) are NOT affected by this cve so it's safe to revert it. The offending commit was introduced upstream in v4.8-rc1. At this point had nothing to do with any CVE. It was related with CVE-2018-16597 as it was the fix for bug [1]. Then it was backported to stable 4.4 and this way it ended up in Ubuntu 4.4 kernels. [Test Case] ----> Offending commit breaks r/w access in overlayfs Reproducer available in [2]. To run the reproducer : $./make-overlay.sh $./test.sh # With the offending commit in place : $ ./test.sh st_mode is 100644 open failed: -1 cat: /tmp/overlay/animal: Permission denied <---- Breaks access -rw-r--r-- 1 jo jo 0 Oct 11 09:57 /tmp/overlay/animal # With the offending commit reverted : $ ./test.sh st_mode is 100644 -rw-r--r-- 1 jo jo 0 Oct 11 16:01 /tmp/overlay/animal [Other] ----> Test whether 4.4 kernels are affected by CVE-2018-16597 Since offending commit c0ca3d70e8d3(ovl: modify ovl_permission() to do checks on two inodes) is related with CVE-2018-16597 a test script is provided to confirm that 4.4 kernel are not affected by this cve and therefore is safe to revert the commit. Kernels tested : 4.4 ESM kernels : - 4.4.0-1057-aws (offending reverted) PASS - 4.4.0-167-generic (offending reverted) PASS 4.4 AWS Kenrels (not esm) : - 4.4.0-1097-aws as is PASS - 4.4.0-1097-aws offending reverted PASS 4.4 Generic kernels (not esm) : - 4.4.0-165-generic as is PASS - 4.4.0-165-generic (offending reverted) PASS Upstream kernels : - latest upstream PASS - upstream at offending PASS - upstream before offending PASS - 4.4 stable before offending PASS ### DETAILS A simple script is attached (test_overlay_permission.sh) to test whether ubuntu 4.4 kernels are affected by CVE-2018-16597. They are not. Neither is the stable 4.4.y upstream kernel. The script tests for the reproducer found in [1] and a modified version of it that doesn't breaks the following (quoting from [3] ): "Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed. If the underlying filesystem is changed, the behavior of the overlay is undefined, though it will not result in a crash or deadlock." These two test cases should fail. So, expect to see "cp: cannot create regular file <the file we're writing>: Permission denied". Then there are a few other test cases (files placed in lower/upper dirs and owned by root/user). The script checks the contents of the files at the end and reports anything wrong by printing : Problem with file <file> and then cat-ing the file and listing the permissions. An example (correct) output is the following : ---------------------------------------------------------------------- $ ./test_overlay_permission.sh Testing reproducer This should fail cp: cannot create regular file '/home/jo/test_cve/overlay/bash': Permission denied Testing reproducer modified This should fail cp: cannot create regular file '/home/jo/test_cve/overlay/bash': Permission denied Testing other cases ./test_overlay_permission.sh: line 100: /home/jo/test_cve/overlay/after_mount_root: Permission denied ./test_overlay_permission.sh: line 100: /home/jo/test_cve/overlay/both_root: Permission denied ./test_overlay_permission.sh: line 100: /home/jo/test_cve/overlay/lower_only_root: Permission denied ./test_overlay_permission.sh: line 100: /home/jo/test_cve/overlay/upper_only_root: Permission denied ########################################################## CHECK LOWER ########################################################## CHECK UPPER ########################################################## CHECK OVERLAY ---------------------------------------------------------------------- We see that when "Testing reproducer" it fails so we are OK. In addition, when "Testing other cases" we get 4 "Permission denied", which is also the desired behaviour as a user is trying to write root-owned files. In case, there's output after CHECK LOWER/UPPER/OERLAY something has gone wrong and needs investigation. In the case above, nothing is printed so we're good. [1] https://bugzilla.suse.com/show_bug.cgi?id=1106512#c0 [2] https://gist.github.com/thomas-holmes/711bcdb28e2b8e6d1c39c1d99d292af7 [3] linux/Documentation/overlayfs.txt To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851243/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
