Blame SOURCES/CVE-2021-0920.patch

c6ac4c
From 10bde99768d3c92f5fde1ec51f74e926fc4cf779 Mon Sep 17 00:00:00 2001
c6ac4c
From: Artem Savkov <asavkov@redhat.com>
c6ac4c
Date: Thu, 27 Jan 2022 11:44:06 +0100
c6ac4c
Subject: [KPATCH CVE-2021-0920] af_unix: fix garbage collect vs MSG_PEEK
c6ac4c
c6ac4c
Kernels:
c6ac4c
- 3.10.0-1160.15.2.el7
c6ac4c
- 3.10.0-1160.21.1.el7
c6ac4c
- 3.10.0-1160.24.1.el7
c6ac4c
- 3.10.0-1160.25.1.el7
c6ac4c
- 3.10.0-1160.31.1.el7
c6ac4c
- 3.10.0-1160.36.2.el7
c6ac4c
- 3.10.0-1160.41.1.el7
c6ac4c
- 3.10.0-1160.42.2.el7
c6ac4c
- 3.10.0-1160.45.1.el7
c6ac4c
- 3.10.0-1160.49.1.el7
c6ac4c
- 3.10.0-1160.53.1.el7
c6ac4c
c6ac4c
Changes since last build:
c6ac4c
c6ac4c
arches: x86_64 ppc64le
c6ac4c
- af_unix.o: changed function: unix_dgram_recvmsg
c6ac4c
- af_unix.o: changed function: unix_stream_read_generic
c6ac4c
- garbage.o: new function: unix_peek_fds
c6ac4c
----
c6ac4c
c6ac4c
Kpatch-MR: https://gitlab.com/redhat/prdsc/rhel/src/kpatch/rhel-7/-/merge_requests/18
c6ac4c
Approved-by: Joe Lawrence (@joe.lawrence)
c6ac4c
Approved-by: Yannick Cote (@ycote1)
c6ac4c
Kernels:
c6ac4c
3.10.0-1160.21.1.el7
c6ac4c
3.10.0-1160.24.1.el7
c6ac4c
3.10.0-1160.25.1.el7
c6ac4c
3.10.0-1160.31.1.el7
c6ac4c
3.10.0-1160.36.2.el7
c6ac4c
3.10.0-1160.41.1.el7
c6ac4c
3.10.0-1160.42.2.el7
c6ac4c
3.10.0-1160.45.1.el7
c6ac4c
3.10.0-1160.49.1.el7
c6ac4c
3.10.0-1160.53.1.el7
c6ac4c
c6ac4c
Modifications: moved unix_peek_fds() to net/unix/garbage.c to avoid
c6ac4c
changing unix_gc_lock scope.
c6ac4c
c6ac4c
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2031986
c6ac4c
c6ac4c
Z-MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-7/-/merge_requests/379
c6ac4c
c6ac4c
commit ab0fd1713f1efeb2c859d32721625ea98cd9e663
c6ac4c
Author: William Zhao <wizhao@redhat.com>
c6ac4c
Date:   Wed Jan 19 09:29:17 2022 -0500
c6ac4c
c6ac4c
    af_unix: fix garbage collect vs MSG_PEEK
c6ac4c
c6ac4c
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2031970
c6ac4c
    Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
c6ac4c
    CVE: CVE-2021-0920
c6ac4c
    Conflicts: The code still uses the old "sock_iocb" structure since rhel-7
c6ac4c
    does not have the commit 7cc05662682da ("net: remove sock_iocb"). Thus
c6ac4c
    passing the "scm_cookie" pointer to the "unix_peek_fds" was slightly
c6ac4c
    modified to use "siocb->scm" instead of just "&scm". Additionally
c6ac4c
    the "unix_gc_lock" is not exposed to "af_unix.c" via a header file since
c6ac4c
    rhel-7 does not have the commit f4e65870e5ce ("net: split out functions
c6ac4c
    related to registering inflight socket files"). Bringing in the commit
c6ac4c
    will add a new UNIX_SCM kernel config; this can be avoided by adding
c6ac4c
    extern-ing the "unix_gc_lock".
c6ac4c
c6ac4c
    commit cbcf01128d0a92e131bd09f1688fe032480b65ca
c6ac4c
    Author: Miklos Szeredi <mszeredi@redhat.com>
c6ac4c
    Date:   Wed Jul 28 14:47:20 2021 +0200
c6ac4c
c6ac4c
        af_unix: fix garbage collect vs MSG_PEEK
c6ac4c
c6ac4c
        unix_gc() assumes that candidate sockets can never gain an external
c6ac4c
        reference (i.e.  be installed into an fd) while the unix_gc_lock is
c6ac4c
        held.  Except for MSG_PEEK this is guaranteed by modifying inflight
c6ac4c
        count under the unix_gc_lock.
c6ac4c
c6ac4c
        MSG_PEEK does not touch any variable protected by unix_gc_lock (file
c6ac4c
        count is not), yet it needs to be serialized with garbage collection.
c6ac4c
        Do this by locking/unlocking unix_gc_lock:
c6ac4c
c6ac4c
         1) increment file count
c6ac4c
c6ac4c
         2) lock/unlock barrier to make sure incremented file count is visible
c6ac4c
            to garbage collection
c6ac4c
c6ac4c
         3) install file into fd
c6ac4c
c6ac4c
        This is a lock barrier (unlike smp_mb()) that ensures that garbage
c6ac4c
        collection is run completely before or completely after the barrier.
c6ac4c
c6ac4c
        Cc: <stable@vger.kernel.org>
c6ac4c
        Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
c6ac4c
        Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
c6ac4c
        Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
c6ac4c
    Signed-off-by: William Zhao <wizhao@redhat.com>
c6ac4c
c6ac4c
Signed-off-by: Artem Savkov <asavkov@redhat.com>
c6ac4c
---
c6ac4c
 net/unix/af_unix.c |  7 +++++--
c6ac4c
 net/unix/garbage.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++
c6ac4c
 2 files changed, 52 insertions(+), 2 deletions(-)
c6ac4c
c6ac4c
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
c6ac4c
index bcb0ad54b9b3..a264b4598872 100644
c6ac4c
--- a/net/unix/af_unix.c
c6ac4c
+++ b/net/unix/af_unix.c
c6ac4c
@@ -1468,6 +1468,8 @@ out:
c6ac4c
 	return err;
c6ac4c
 }
c6ac4c
 
c6ac4c
+void unix_peek_fds(struct scm_cookie *scm, struct sk_buff *skb);
c6ac4c
+
c6ac4c
 static void unix_detach_fds(struct scm_cookie *scm, struct sk_buff *skb)
c6ac4c
 {
c6ac4c
 	int i;
c6ac4c
@@ -2182,7 +2184,8 @@ static int unix_dgram_recvmsg(struct kiocb *iocb, struct socket *sock,
c6ac4c
 		sk_peek_offset_fwd(sk, size);
c6ac4c
 
c6ac4c
 		if (UNIXCB(skb).fp)
c6ac4c
-			siocb->scm->fp = scm_fp_dup(UNIXCB(skb).fp);
c6ac4c
+			unix_peek_fds(siocb->scm, skb);
c6ac4c
+
c6ac4c
 	}
c6ac4c
 	err = (flags & MSG_TRUNC) ? skb->len - skip : size;
c6ac4c
 
c6ac4c
@@ -2432,7 +2435,7 @@ unlock:
c6ac4c
 			/* It is questionable, see note in unix_dgram_recvmsg.
c6ac4c
 			 */
c6ac4c
 			if (UNIXCB(skb).fp)
c6ac4c
-				siocb->scm->fp = scm_fp_dup(UNIXCB(skb).fp);
c6ac4c
+				unix_peek_fds(siocb->scm, skb);
c6ac4c
 
c6ac4c
 			sk_peek_offset_fwd(sk, chunk);
c6ac4c
 
c6ac4c
diff --git a/net/unix/garbage.c b/net/unix/garbage.c
c6ac4c
index c36757e72844..f242268477ba 100644
c6ac4c
--- a/net/unix/garbage.c
c6ac4c
+++ b/net/unix/garbage.c
c6ac4c
@@ -374,3 +374,50 @@ void unix_gc(void)
c6ac4c
  out:
c6ac4c
 	spin_unlock(&unix_gc_lock);
c6ac4c
 }
c6ac4c
+
c6ac4c
+void unix_peek_fds(struct scm_cookie *scm, struct sk_buff *skb)
c6ac4c
+{
c6ac4c
+	scm->fp = scm_fp_dup(UNIXCB(skb).fp);
c6ac4c
+
c6ac4c
+	/*
c6ac4c
+	 * Garbage collection of unix sockets starts by selecting a set of
c6ac4c
+	 * candidate sockets which have reference only from being in flight
c6ac4c
+	 * (total_refs == inflight_refs).  This condition is checked once during
c6ac4c
+	 * the candidate collection phase, and candidates are marked as such, so
c6ac4c
+	 * that non-candidates can later be ignored.  While inflight_refs is
c6ac4c
+	 * protected by unix_gc_lock, total_refs (file count) is not, hence this
c6ac4c
+	 * is an instantaneous decision.
c6ac4c
+	 *
c6ac4c
+	 * Once a candidate, however, the socket must not be reinstalled into a
c6ac4c
+	 * file descriptor while the garbage collection is in progress.
c6ac4c
+	 *
c6ac4c
+	 * If the above conditions are met, then the directed graph of
c6ac4c
+	 * candidates (*) does not change while unix_gc_lock is held.
c6ac4c
+	 *
c6ac4c
+	 * Any operations that changes the file count through file descriptors
c6ac4c
+	 * (dup, close, sendmsg) does not change the graph since candidates are
c6ac4c
+	 * not installed in fds.
c6ac4c
+	 *
c6ac4c
+	 * Dequeing a candidate via recvmsg would install it into an fd, but
c6ac4c
+	 * that takes unix_gc_lock to decrement the inflight count, so it's
c6ac4c
+	 * serialized with garbage collection.
c6ac4c
+	 *
c6ac4c
+	 * MSG_PEEK is special in that it does not change the inflight count,
c6ac4c
+	 * yet does install the socket into an fd.  The following lock/unlock
c6ac4c
+	 * pair is to ensure serialization with garbage collection.  It must be
c6ac4c
+	 * done between incrementing the file count and installing the file into
c6ac4c
+	 * an fd.
c6ac4c
+	 *
c6ac4c
+	 * If garbage collection starts after the barrier provided by the
c6ac4c
+	 * lock/unlock, then it will see the elevated refcount and not mark this
c6ac4c
+	 * as a candidate.  If a garbage collection is already in progress
c6ac4c
+	 * before the file count was incremented, then the lock/unlock pair will
c6ac4c
+	 * ensure that garbage collection is finished before progressing to
c6ac4c
+	 * installing the fd.
c6ac4c
+	 *
c6ac4c
+	 * (*) A -> B where B is on the queue of A or B is on the queue of C
c6ac4c
+	 * which is on the queue of listening socket A.
c6ac4c
+	 */
c6ac4c
+	spin_lock(&unix_gc_lock);
c6ac4c
+	spin_unlock(&unix_gc_lock);
c6ac4c
+}
c6ac4c
-- 
c6ac4c
2.26.3
c6ac4c
c6ac4c