CVE-2021-46929: sctp: use call_rcu to free endpoint
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.
Security readout for executives and security teams
Plain-English summary
CVE-2021-46929 is a Linux kernel memory-safety bug in SCTP handling. Under a race involving SCTP association peeloff and diagnostic dumping, the kernel could access freed memory. The supplied sources do not provide CVSS, impact scoring, or evidence of exploitation.
Executive priority
Treat as a kernel maintenance item unless SCTP is used on critical systems or vendor advisories rate it higher. Lack of CVSS and exploit evidence limits urgency, but kernel memory bugs should not remain untracked.
Technical view
The flaw is a use-after-free in Linux SCTP code reached through sctp_sock_dump() during inet/sock diagnostic dumping. The fix delays endpoint freeing with call_rcu(), moves sock_put and endpoint free into sctp_endpoint_destroy_rcu(), and skips dead or changed endpoints during traversal.
Likely exposure
Exposure is limited to Linux systems running affected kernel builds where SCTP code paths are present. The bundle identifies Linux kernel versions/lines including 4.14, 4.19.224, 5.4.170, 5.10.90, 5.15.13, and 5.16, but exact downstream package status requires vendor confirmation.
Exploitation context
The supplied sources describe a kernel use-after-free discovered through KASAN traces. They do not state active exploitation, public exploit availability, remote reachability, privilege requirements, or business impact. KEV status is false in the bundle.
Researcher notes
The core race involves asoc peeloff, stale asoc->base.sk access, and sctp_sock_dump() locking. The patch uses RCU lifetime protection and endpoint hold checks, with additional safeguards when the endpoint changes during dumping.
Mitigation direction
Check Linux distribution advisories for CVE-2021-46929 package status.
Update kernels to builds containing the referenced stable SCTP fixes.
Prioritize systems that enable or rely on SCTP workloads.
Confirm reboot or live-patch completion after kernel remediation.
Validation and detection
Inventory Linux kernel versions across servers, appliances, and containers hosts.
Check vendor changelogs for CVE-2021-46929 or referenced stable commits.
Determine whether SCTP modules or workloads are enabled in production.
Review kernel crash, KASAN, or lockdep logs for related SCTP diagnostics traces.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2021-46929 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.