CVE-2021-46929

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 callrcu() to fix another use-after-free issue in sctpsock_dump():

BUG: KASAN: use-after-free in _lockacquire+0x36d9/0x4c20 Call Trace: _lockacquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lockacquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 _rawspinlockbh include/linux/spinlockapismp.h:135 [inline] _rawspinlockbh+0x31/0x40 kernel/locking/spinlock.c:168 spinlockbh include/linux/spinlock.h:334 [inline] _locksock+0x203/0x350 net/core/sock.c:2253 locksocknested+0xfe/0x120 net/core/sock.c:2774 locksock include/net/sock.h:1492 [inline] sctpsockdump+0x122/0xb20 net/sctp/diag.c:324 sctpforeachtransport+0x2b5/0x370 net/sctp/socket.c:5091 sctpdiagdump+0x3ac/0x660 net/sctp/diag.c:527 _inetdiagdump+0xa8/0x140 net/ipv4/inetdiag.c:1049 inetdiagdump+0x9b/0x110 net/ipv4/inetdiag.c:1065 netlinkdump+0x606/0x1080 net/netlink/afnetlink.c:2244 _netlinkdumpstart+0x59a/0x7c0 net/netlink/afnetlink.c:2352 netlinkdumpstart include/linux/netlink.h:216 [inline] inetdiaghandlercmd+0x2ce/0x3f0 net/ipv4/inetdiag.c:1170 _sockdiagcmd net/core/sockdiag.c:232 [inline] sockdiagrcvmsg+0x31d/0x410 net/core/sockdiag.c:263 netlinkrcvskb+0x172/0x440 net/netlink/afnetlink.c:2477 sockdiagrcv+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 locksock(). This patch uses callrcu() and moves sockput and ep free into sctpendpointdestroyrcu(), so that it's safe to try to hold the ep under rcureadlock in sctptransporttraverse_process().

If sctpendpointhold() 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 rcureadunlock, and we should skip it.

In sctpsockdump(), 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 locksock(), 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 locksock, 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 sctpendpointdestroy() before calling callrcu(). Also, freeing endpoint by callrcu() makes it safe to access the sk by asoc->base.sk in sctpassocsseqshow() and sctprcv().

Thanks Jones to bring this issue up.

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