cve request: overlayfs: Fix dentry reference leak

[CAI Qian <caiqian () redhat com>]

=== Description ===
commit ab79efab0a0ba01a74df782eb7fa44b044dae8b5 upstream.

In ovl_copy_up_locked(), newdentry is leaked if the function exits through
out_cleanup as this just to out after calling ovl_cleanup() - which doesn't
actually release the ref on newdentry.

The out_cleanup segment should instead exit through out2 as certainly
newdentry leaks - and possibly upper does also, though this isn't caught
given the catch of newdentry.

Without this fix, something like the following is seen:

        BUG: Dentry ffff880023e9eb20{i=f861,n=#ffff880023e82d90} still in use (1) [unmount of tmpfs tmpfs]
        BUG: Dentry ffff880023ece640{i=0,n=bigfile}  still in use (1) [unmount of tmpfs tmpfs]

when unmounting the upper layer after an error occurred in copyup.

An error can be induced by creating a big file in a lower layer with
something like:

        dd if=/dev/zero of=/lower/a/bigfile bs=65536 count=1 seek=$((0xf000))

to create a large file (4.1G).  Overlay an upper layer that is too small
(on tmpfs might do) and then induce a copy up by opening it writably.

=== POC Exploit ===
This can be reproduced in a DevOps environment when the docker runtime storage is on overlayfs over
xfs as a local DoS. An attacker access to a developer account could run a crafted image from elsewhere
like docker by creating a big file in the container filesystem and try to read it running by any
user like below by forcing xfs_file_open() returns -EFBIG,

$ cat Dockerfile
FROM fedora
USER nobody
RUN dd if=/dev/zero of=/home/nobody/bigfile bs=1024k seek=2046 count=1
ADD open /home/nobody
CMD ["/home/nobody/open", "/home/nobody/bigfile"]

and possibly trigger kernel dentry leaks inside the container that will eventually running out of
kernel resources for other developers. Hence, a local DoS.
   CAI Qian