CVE-2022-50243
Unknown
Unknown - Not Provided
BaseFortify
Publication date: 2025-09-15
Last updated on: 2025-11-24
Assigner: kernel.org
Description
Description
In the Linux kernel, the following vulnerability has been resolved:
sctp: handle the error returned from sctp_auth_asoc_init_active_key
When it returns an error from sctp_auth_asoc_init_active_key(), the
active_key is actually not updated. The old sh_key will be freeed
while it's still used as active key in asoc. Then an use-after-free
will be triggered when sending patckets, as found by syzbot:
sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112
sctp_set_owner_w net/sctp/socket.c:132 [inline]
sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863
sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025
inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:734
This patch is to fix it by not replacing the sh_key when it returns
errors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key().
For sctp_auth_set_active_key(), old active_key_id will be set back
to asoc->active_key_id when the same thing happens.
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| linux | linux_kernel | 5.14 |
| linux | linux_kernel | 5.14 |
| linux | linux_kernel | 5.14 |
| linux | linux_kernel | 5.14 |
| linux | linux_kernel | 5.14 |
| linux | linux_kernel | 5.14 |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-416 | The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |