CVE-2022-49209
published 2025-02-26CVE-2022-49209: In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full If tcp_bpf_sendmsg() is…
PriorityP418medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.26%
18.1th percentile
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full
If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()
returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial
memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is
greater than osize after sk_msg_alloc(), memleak occurs. To fix we use
sk_msg_trim() to release the allocated memory, then goto wait for memory.
Other call paths of sk_msg_alloc() have the similar issue, such as
tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),
as Cong Wang suggested.
This issue can cause the following info:
WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
Call Trace:
inet_csk_destroy_sock+0x55/0x110
__tcp_close+0x279/0x470
tcp_close+0x1f/0x60
inet_release+0x3f/0x80
__sock_release+0x3d/0xb0
sock_close+0x11/0x20
__fput+0x92/0x250
task_work_run+0x6a/0xa0
do_exit+0x33b/0xb60
do_group_exit+0x2f/0xa0
get_signal+0xb6/0x950
arch_do_signal_or_restart+0xac/0x2a0
exit_to_user_mode_prepare+0xa9/0x200
syscall_exit_to_user_mode+0x12/0x30
do_syscall_64+0x46/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
__sk_destruct+0x24/0x1f0
sk_psock_destroy+0x19b/0x1c0
process_one_work+0x1b3/0x3c0
kthread+0xe6/0x110
ret_from_fork+0x22/0x30
Affected
17 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.17.3-1 (bookworm) | linux 5.17.3-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 604326b41a6fb9b4a78b6179335decee0365cd8c < 6d03722c34d9603df325f67c6d30dc1b7b3c6067 | 6d03722c34d9603df325f67c6d30dc1b7b3c6067 |
| linux | linux | >= 604326b41a6fb9b4a78b6179335decee0365cd8c < bec34a91eba3483e1830c02bdd36f8f968642047 | bec34a91eba3483e1830c02bdd36f8f968642047 |
| linux | linux | >= 604326b41a6fb9b4a78b6179335decee0365cd8c < de3a8d8fab0710186f7864ec812836d8d70da3c9 | de3a8d8fab0710186f7864ec812836d8d70da3c9 |
| linux | linux | >= 604326b41a6fb9b4a78b6179335decee0365cd8c < f677328f05f52d535cbdc15cb04476db49477eb4 | f677328f05f52d535cbdc15cb04476db49477eb4 |
| linux | linux | >= 604326b41a6fb9b4a78b6179335decee0365cd8c < d0b85dfc6f01d26808e2576c6537c131b590e270 | d0b85dfc6f01d26808e2576c6537c131b590e270 |
| linux | linux | >= 604326b41a6fb9b4a78b6179335decee0365cd8c < 9c34e38c4a870eb30b13f42f5b44f42e9d19ccb8 | 9c34e38c4a870eb30b13f42f5b44f42e9d19ccb8 |
| linux | linux_kernel | >= 0 < 5.10.113-1 | 5.10.113-1 |
| linux | linux_kernel | >= 0 < 5.17.3-1 | 5.17.3-1 |
| linux | linux_kernel | >= 0 < 5.17.3-1 | 5.17.3-1 |
| linux | linux_kernel | >= 0 < 5.17.3-1 | 5.17.3-1 |
| linux | linux_kernel | >= 4.20 < 5.4.189 | 5.4.189 |
| linux | linux_kernel | >= 5.11 < 5.15.33 | 5.15.33 |
| linux | linux_kernel | >= 5.16 < 5.16.19 | 5.16.19 |
| linux | linux_kernel | >= 5.17 < 5.17.2 | 5.17.2 |
| linux | linux_kernel | >= 5.5 < 5.10.110 | 5.10.110 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full
vendor_redhat·2025-02-26·CVSS 5.5
CVE-2022-49209 [MEDIUM] CWE-401 kernel: bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full
kernel: bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full
If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()
returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial
memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is
greater than osize after sk_msg_alloc(), memleak occurs. To fix we use
sk_msg_trim() to release the allocated memory, then goto wait for memory.
Other call paths of sk_msg_alloc() have the similar issue, such as
tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),
as Cong Wang suggested.
This issue can cause the following info:
WARNING: CPU: 3 PID: 79
Debian
CVE-2022-49209: linux - In the Linux kernel, the following vulnerability has been resolved: bpf, sockma...
vendor_debian·2022·CVSS 5.5
CVE-2022-49209 [MEDIUM] CVE-2022-49209: linux - In the Linux kernel, the following vulnerability has been resolved: bpf, sockma...
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc() returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is greater than osize after sk_msg_alloc(), memleak occurs. To fix we use sk_msg_trim() to release the allocated memory, then goto wait for memory. Other call paths of sk_msg_alloc() have the similar issue, such as tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(), as Cong Wang suggested. This issue can cause the following info: WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0 Call Trace: in
GHSA
GHSA-pp5f-f2rv-q3vx: In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full
If tcp_bpf_sen
ghsa_unreviewed·2025-03-18
CVE-2022-49209 [MEDIUM] CWE-401 GHSA-pp5f-f2rv-q3vx: In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full
If tcp_bpf_sen
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full
If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()
returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial
memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is
greater than osize after sk_msg_alloc(), memleak occurs. To fix we use
sk_msg_trim() to release the allocated memory, then goto wait for memory.
Other call paths of sk_msg_alloc() have the similar issue, such as
tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),
as Cong Wang suggested.
This issue can cause the following info:
WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
Call Trace
OSV
CVE-2022-49209: In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full If tcp_bpf_sendm
osv·2025-02-26·CVSS 5.5
CVE-2022-49209 [MEDIUM] CVE-2022-49209: In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full If tcp_bpf_sendm
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc() returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is greater than osize after sk_msg_alloc(), memleak occurs. To fix we use sk_msg_trim() to release the allocated memory, then goto wait for memory. Other call paths of sk_msg_alloc() have the similar issue, such as tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(), as Cong Wang suggested. This issue can cause the following info: WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0 Call Trace: in
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/6d03722c34d9603df325f67c6d30dc1b7b3c6067https://git.kernel.org/stable/c/9c34e38c4a870eb30b13f42f5b44f42e9d19ccb8https://git.kernel.org/stable/c/bec34a91eba3483e1830c02bdd36f8f968642047https://git.kernel.org/stable/c/d0b85dfc6f01d26808e2576c6537c131b590e270https://git.kernel.org/stable/c/de3a8d8fab0710186f7864ec812836d8d70da3c9https://git.kernel.org/stable/c/f677328f05f52d535cbdc15cb04476db49477eb4
2025-02-26
Published