cve/published/2021/CVE-2021-46929.mbox

From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: <linux-cve-announce@vger.kernel.org>
Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: CVE-2021-46929: sctp: use call_rcu to free endpoint

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

sctp: use call_rcu to free endpoint

This patch is to delay the endpoint free by calling call_rcu() to fix
another use-after-free issue in sctp_sock_dump():

  BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20
  Call Trace:
    __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218
    lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
    __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
    _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
    spin_lock_bh include/linux/spinlock.h:334 [inline]
    __lock_sock+0x203/0x350 net/core/sock.c:2253
    lock_sock_nested+0xfe/0x120 net/core/sock.c:2774
    lock_sock include/net/sock.h:1492 [inline]
    sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324
    sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091
    sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527
    __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049
    inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065
    netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244
    __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352
    netlink_dump_start include/linux/netlink.h:216 [inline]
    inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170
    __sock_diag_cmd net/core/sock_diag.c:232 [inline]
    sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263
    netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477
    sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274

This issue occurs when asoc is peeled off and the old sk is freed after
getting it by asoc->base.sk and before calling lock_sock(sk).

To prevent the sk free, as a holder of the sk, ep should be alive when
calling lock_sock(). This patch uses call_rcu() and moves sock_put and
ep free into sctp_endpoint_destroy_rcu(), so that it's safe to try to
hold the ep under rcu_read_lock in sctp_transport_traverse_process().

If sctp_endpoint_hold() returns true, it means this ep is still alive
and we have held it and can continue to dump it; If it returns false,
it means this ep is dead and can be freed after rcu_read_unlock, and
we should skip it.

In sctp_sock_dump(), after locking the sk, if this ep is different from
tsp->asoc->ep, it means during this dumping, this asoc was peeled off
before calling lock_sock(), and the sk should be skipped; If this ep is
the same with tsp->asoc->ep, it means no peeloff happens on this asoc,
and due to lock_sock, no peeloff will happen either until release_sock.

Note that delaying endpoint free won't delay the port release, as the
port release happens in sctp_endpoint_destroy() before calling call_rcu().
Also, freeing endpoint by call_rcu() makes it safe to access the sk by
asoc->base.sk in sctp_assocs_seq_show() and sctp_rcv().

Thanks Jones to bring this issue up.

v1->v2:
  - improve the changelog.
  - add kfree(ep) into sctp_endpoint_destroy_rcu(), as Jakub noticed.

The Linux kernel CVE team has assigned CVE-2021-46929 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.14 with commit d25adbeb0cdb860fb39e09cdd025e9cfc954c5ab and fixed in 4.14.261 with commit 8873140f95d4977bf37e4cf0d5c5e3f6e34cdd3e
	Issue introduced in 4.14 with commit d25adbeb0cdb860fb39e09cdd025e9cfc954c5ab and fixed in 4.19.224 with commit af6e6e58f7ebf86b4e7201694b1e4f3a62cbc3ec
	Issue introduced in 4.14 with commit d25adbeb0cdb860fb39e09cdd025e9cfc954c5ab and fixed in 5.4.170 with commit 831de271452b87657fcf8d715ee20519b79caef5
	Issue introduced in 4.14 with commit d25adbeb0cdb860fb39e09cdd025e9cfc954c5ab and fixed in 5.10.90 with commit 769d14abd35e0e153b5149c3e1e989a9d719e3ff
	Issue introduced in 4.14 with commit d25adbeb0cdb860fb39e09cdd025e9cfc954c5ab and fixed in 5.15.13 with commit 75799e71df1da11394740b43ae5686646179561d
	Issue introduced in 4.14 with commit d25adbeb0cdb860fb39e09cdd025e9cfc954c5ab and fixed in 5.16 with commit 5ec7d18d1813a5bead0b495045606c93873aecbb

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2021-46929
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	include/net/sctp/sctp.h
	include/net/sctp/structs.h
	net/sctp/diag.c
	net/sctp/endpointola.c
	net/sctp/socket.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/8873140f95d4977bf37e4cf0d5c5e3f6e34cdd3e
	https://git.kernel.org/stable/c/af6e6e58f7ebf86b4e7201694b1e4f3a62cbc3ec
	https://git.kernel.org/stable/c/831de271452b87657fcf8d715ee20519b79caef5
	https://git.kernel.org/stable/c/769d14abd35e0e153b5149c3e1e989a9d719e3ff
	https://git.kernel.org/stable/c/75799e71df1da11394740b43ae5686646179561d
	https://git.kernel.org/stable/c/5ec7d18d1813a5bead0b495045606c93873aecbb