Blame SOURCES/CVE-2021-0920.patch

ec80f5
From 18c390171a63c1be8df1a62172214efbd9e84813 Mon Sep 17 00:00:00 2001
ec80f5
From: Joe Lawrence <joe.lawrence@redhat.com>
ec80f5
Date: Thu, 20 Jan 2022 14:39:19 -0500
ec80f5
Subject: [KPATCH CVE-2021-0920] af_unix: kpatch fixes for CVE-2021-0920
ec80f5
ec80f5
Kernels:
ec80f5
4.18.0-348.el8
ec80f5
4.18.0-348.2.1.el8_5
ec80f5
4.18.0-348.7.1.el8_5
ec80f5
4.18.0-348.12.2.el8_5
ec80f5
ec80f5
Changes since last build:
ec80f5
arches: x86_64 ppc64le
ec80f5
af_unix.o: changed function: unix_dgram_recvmsg
ec80f5
af_unix.o: changed function: unix_stream_read_generic
ec80f5
---------------------------
ec80f5
ec80f5
Kpatch-MR: https://gitlab.com/redhat/prdsc/rhel/src/kpatch/rhel-8/-/merge_requests/17
ec80f5
Approved-by: Yannick Cote (@ycote1)
ec80f5
Approved-by: Artem Savkov (@artem.savkov)
ec80f5
Kernels:
ec80f5
4.18.0-348.el8
ec80f5
4.18.0-348.2.1.el8_5
ec80f5
4.18.0-348.7.1.el8_5
ec80f5
4.18.0-348.12.2.el8_5
ec80f5
ec80f5
Modifications: none
ec80f5
ec80f5
commit 49c79494c048e940be91a9454c2f507bc33680fc
ec80f5
Author: Patrick Talbert <ptalbert@redhat.com>
ec80f5
Date:   Mon Jan 10 13:13:05 2022 +0100
ec80f5
ec80f5
    af_unix: fix garbage collect vs MSG_PEEK
ec80f5
ec80f5
    Bugzilla: https://bugzilla.redhat.com/2031974
ec80f5
    CVE: CVE-2021-0920
ec80f5
    Y-Commit: 35c0f6eeb4644e87e7f3c1198a9f31b76220053d
ec80f5
ec80f5
    O-CVE: CVE-2021-0920
ec80f5
    O-Bugzilla: https://bugzilla.redhat.com/2031975
ec80f5
    Upstream status: main
ec80f5
    Testing: Sanity only
ec80f5
ec80f5
    commit cbcf01128d0a92e131bd09f1688fe032480b65ca
ec80f5
    Author: Miklos Szeredi <mszeredi@redhat.com>
ec80f5
    Date:   Wed Jul 28 14:47:20 2021 +0200
ec80f5
ec80f5
        af_unix: fix garbage collect vs MSG_PEEK
ec80f5
ec80f5
        unix_gc() assumes that candidate sockets can never gain an external
ec80f5
        reference (i.e.  be installed into an fd) while the unix_gc_lock is
ec80f5
        held.  Except for MSG_PEEK this is guaranteed by modifying inflight
ec80f5
        count under the unix_gc_lock.
ec80f5
ec80f5
        MSG_PEEK does not touch any variable protected by unix_gc_lock (file
ec80f5
        count is not), yet it needs to be serialized with garbage collection.
ec80f5
        Do this by locking/unlocking unix_gc_lock:
ec80f5
ec80f5
         1) increment file count
ec80f5
ec80f5
         2) lock/unlock barrier to make sure incremented file count is visible
ec80f5
            to garbage collection
ec80f5
ec80f5
         3) install file into fd
ec80f5
ec80f5
        This is a lock barrier (unlike smp_mb()) that ensures that garbage
ec80f5
        collection is run completely before or completely after the barrier.
ec80f5
ec80f5
        Cc: <stable@vger.kernel.org>
ec80f5
        Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ec80f5
        Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
ec80f5
        Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ec80f5
ec80f5
    Signed-off-by: Patrick Talbert <ptalbert@redhat.com>
ec80f5
ec80f5
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
ec80f5
---
ec80f5
 net/unix/af_unix.c | 51 ++++++++++++++++++++++++++++++++++++++++++++--
ec80f5
 1 file changed, 49 insertions(+), 2 deletions(-)
ec80f5
ec80f5
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
ec80f5
index 247e3138d1ef..d9c968caaf20 100644
ec80f5
--- a/net/unix/af_unix.c
ec80f5
+++ b/net/unix/af_unix.c
ec80f5
@@ -1498,6 +1498,53 @@ static int unix_getname(struct socket *sock, struct sockaddr *uaddr, int peer)
ec80f5
 	return err;
ec80f5
 }
ec80f5
 
ec80f5
+static void unix_peek_fds(struct scm_cookie *scm, struct sk_buff *skb)
ec80f5
+{
ec80f5
+	scm->fp = scm_fp_dup(UNIXCB(skb).fp);
ec80f5
+
ec80f5
+	/*
ec80f5
+	 * Garbage collection of unix sockets starts by selecting a set of
ec80f5
+	 * candidate sockets which have reference only from being in flight
ec80f5
+	 * (total_refs == inflight_refs).  This condition is checked once during
ec80f5
+	 * the candidate collection phase, and candidates are marked as such, so
ec80f5
+	 * that non-candidates can later be ignored.  While inflight_refs is
ec80f5
+	 * protected by unix_gc_lock, total_refs (file count) is not, hence this
ec80f5
+	 * is an instantaneous decision.
ec80f5
+	 *
ec80f5
+	 * Once a candidate, however, the socket must not be reinstalled into a
ec80f5
+	 * file descriptor while the garbage collection is in progress.
ec80f5
+	 *
ec80f5
+	 * If the above conditions are met, then the directed graph of
ec80f5
+	 * candidates (*) does not change while unix_gc_lock is held.
ec80f5
+	 *
ec80f5
+	 * Any operations that changes the file count through file descriptors
ec80f5
+	 * (dup, close, sendmsg) does not change the graph since candidates are
ec80f5
+	 * not installed in fds.
ec80f5
+	 *
ec80f5
+	 * Dequeing a candidate via recvmsg would install it into an fd, but
ec80f5
+	 * that takes unix_gc_lock to decrement the inflight count, so it's
ec80f5
+	 * serialized with garbage collection.
ec80f5
+	 *
ec80f5
+	 * MSG_PEEK is special in that it does not change the inflight count,
ec80f5
+	 * yet does install the socket into an fd.  The following lock/unlock
ec80f5
+	 * pair is to ensure serialization with garbage collection.  It must be
ec80f5
+	 * done between incrementing the file count and installing the file into
ec80f5
+	 * an fd.
ec80f5
+	 *
ec80f5
+	 * If garbage collection starts after the barrier provided by the
ec80f5
+	 * lock/unlock, then it will see the elevated refcount and not mark this
ec80f5
+	 * as a candidate.  If a garbage collection is already in progress
ec80f5
+	 * before the file count was incremented, then the lock/unlock pair will
ec80f5
+	 * ensure that garbage collection is finished before progressing to
ec80f5
+	 * installing the fd.
ec80f5
+	 *
ec80f5
+	 * (*) A -> B where B is on the queue of A or B is on the queue of C
ec80f5
+	 * which is on the queue of listening socket A.
ec80f5
+	 */
ec80f5
+	spin_lock(&unix_gc_lock);
ec80f5
+	spin_unlock(&unix_gc_lock);
ec80f5
+}
ec80f5
+
ec80f5
 static int unix_scm_to_skb(struct scm_cookie *scm, struct sk_buff *skb, bool send_fds)
ec80f5
 {
ec80f5
 	int err = 0;
ec80f5
@@ -2124,7 +2171,7 @@ static int unix_dgram_recvmsg(struct socket *sock, struct msghdr *msg,
ec80f5
 		sk_peek_offset_fwd(sk, size);
ec80f5
 
ec80f5
 		if (UNIXCB(skb).fp)
ec80f5
-			scm.fp = scm_fp_dup(UNIXCB(skb).fp);
ec80f5
+			unix_peek_fds(&scm, skb);
ec80f5
 	}
ec80f5
 	err = (flags & MSG_TRUNC) ? skb->len - skip : size;
ec80f5
 
ec80f5
@@ -2365,7 +2412,7 @@ static int unix_stream_read_generic(struct unix_stream_read_state *state,
ec80f5
 			/* It is questionable, see note in unix_dgram_recvmsg.
ec80f5
 			 */
ec80f5
 			if (UNIXCB(skb).fp)
ec80f5
-				scm.fp = scm_fp_dup(UNIXCB(skb).fp);
ec80f5
+				unix_peek_fds(&scm, skb);
ec80f5
 
ec80f5
 			sk_peek_offset_fwd(sk, chunk);
ec80f5
 
ec80f5
-- 
ec80f5
2.34.1
ec80f5
ec80f5