From 61fe578156c4c9bad13e83efdf4a1546c1bab3cd Mon Sep 17 00:00:00 2001

From: Artem Savkov <asavkov@redhat.com>

Date: Mon, 26 Jul 2021 12:27:34 +0200

Subject: [PATCH] can: bcm: delay release of struct bcm_op after

 synchronize_rcu()

Kernels:

4.18.0-305.el8

4.18.0-305.3.1.el8_4

4.18.0-305.7.1.el8_4

4.18.0-305.10.2.el8_4

Changes since last build:

arches: x86_64 ppc64le

bcm.o: changed function: bcm_release

bcm.o: changed function: bcm_sendmsg

---------------------------

Kernels:

4.18.0-305.el8

4.18.0-305.3.1.el8_4

4.18.0-305.7.1.el8_4

4.18.0-305.10.2.el8_4

Modifications: none

commit 14c1d51567d0ef31ef900f6d1641615924fdb239

Author: Hangbin Liu <haliu@redhat.com>

Date:   Mon Jun 28 14:50:49 2021 +0800

    can: bcm: delay release of struct bcm_op after synchronize_rcu()

    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1975058

    Y-Commit: fc088504ba6bee277b7bdc93ab0988b648bb8b81

    Upstream Status: net.git commit d5f9023fa61e

    CVE: CVE-2021-3609

    O-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1975059

    commit d5f9023fa61ee8b94f37a93f08e94b136cf1e463

    Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

    Date:   Sat Jun 19 13:18:13 2021 -0300

        can: bcm: delay release of struct bcm_op after synchronize_rcu()

        can_rx_register() callbacks may be called concurrently to the call to

        can_rx_unregister(). The callbacks and callback data, though, are

        protected by RCU and the struct sock reference count.

        So the callback data is really attached to the life of sk, meaning

        that it should be released on sk_destruct. However, bcm_remove_op()

        calls tasklet_kill(), and RCU callbacks may be called under RCU

        softirq, so that cannot be used on kernels before the introduction of

        HRTIMER_MODE_SOFT.

        However, bcm_rx_handler() is called under RCU protection, so after

        calling can_rx_unregister(), we may call synchronize_rcu() in order to

        wait for any RCU read-side critical sections to finish. That is,

        bcm_rx_handler() won't be called anymore for those ops. So, we only

        free them, after we do that synchronize_rcu().

        Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol")

        Link: https://lore.kernel.org/r/20210619161813.2098382-1-cascardo@canonical.com

        Cc: linux-stable <stable@vger.kernel.org>

        Reported-by: syzbot+0f7e7e5e2f4f40fa89c0@syzkaller.appspotmail.com

        Reported-by: Norbert Slusarek <nslusarek@gmx.net>

        Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

        Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>

        Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

    Signed-off-by: Hangbin Liu <haliu@redhat.com>

Signed-off-by: Artem Savkov <asavkov@redhat.com>

Acked-by: Joe Lawrence <joe.lawrence@redhat.com>

---

 net/can/bcm.c | 7 ++++++-

 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/net/can/bcm.c b/net/can/bcm.c

index 0af8f0db892a3..4ee2fd682afaa 100644

--- a/net/can/bcm.c

+++ b/net/can/bcm.c

@@ -802,6 +802,7 @@ static int bcm_delete_rx_op(struct list_head *ops, struct bcm_msg_head *mh,

 						  bcm_rx_handler, op);

 			list_del(&op->list);

+			synchronize_rcu();

 			bcm_remove_op(op);

 			return 1; /* done */

 		}

@@ -1527,9 +1528,13 @@ static int bcm_release(struct socket *sock)

 					  REGMASK(op->can_id),

 					  bcm_rx_handler, op);

-		bcm_remove_op(op);

 	}

+	synchronize_rcu();

+

+	list_for_each_entry_safe(op, next, &bo->rx_ops, list)

+		bcm_remove_op(op);

+

 #if IS_ENABLED(CONFIG_PROC_FS)

 	/* remove procfs entry */

 	if (net->can.bcmproc_dir && bo->bcm_proc_read)

-- 

2.26.3