fkie_cve-2022-49207
Vulnerability from fkie_nvd
Published
2025-02-26 07:00
Modified
2025-03-18 20:11
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix memleak in sk_psock_queue_msg
If tcp_bpf_sendmsg is running during a tear down operation we may enqueue
data on the ingress msg queue while tear down is trying to free it.
sk1 (redirect sk2) sk2
------------------- ---------------
tcp_bpf_sendmsg()
tcp_bpf_send_verdict()
tcp_bpf_sendmsg_redir()
bpf_tcp_ingress()
sock_map_close()
lock_sock()
lock_sock() ... blocking
sk_psock_stop
sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED);
release_sock(sk);
lock_sock()
sk_mem_charge()
get_page()
sk_psock_queue_msg()
sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED);
drop_sk_msg()
release_sock()
While drop_sk_msg(), the msg has charged memory form sk by sk_mem_charge
and has sg pages need to put. To fix we use sk_msg_free() and then kfee()
msg.
This issue can cause the following info:
WARNING: CPU: 0 PID: 9202 at net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0
Call Trace:
<IRQ>
inet_csk_destroy_sock+0x55/0x110
tcp_rcv_state_process+0xe5f/0xe90
? sk_filter_trim_cap+0x10d/0x230
? tcp_v4_do_rcv+0x161/0x250
tcp_v4_do_rcv+0x161/0x250
tcp_v4_rcv+0xc3a/0xce0
ip_protocol_deliver_rcu+0x3d/0x230
ip_local_deliver_finish+0x54/0x60
ip_local_deliver+0xfd/0x110
? ip_protocol_deliver_rcu+0x230/0x230
ip_rcv+0xd6/0x100
? ip_local_deliver+0x110/0x110
__netif_receive_skb_one_core+0x85/0xa0
process_backlog+0xa4/0x160
__napi_poll+0x29/0x1b0
net_rx_action+0x287/0x300
__do_softirq+0xff/0x2fc
do_softirq+0x79/0x90
</IRQ>
WARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0
Call Trace:
<TASK>
__sk_destruct+0x24/0x1f0
sk_psock_destroy+0x19b/0x1c0
process_one_work+0x1b3/0x3c0
? process_one_work+0x3c0/0x3c0
worker_thread+0x30/0x350
? process_one_work+0x3c0/0x3c0
kthread+0xe6/0x110
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x22/0x30
</TASK>
References
Impacted products
Vendor | Product | Version | |
---|---|---|---|
linux | linux_kernel | * | |
linux | linux_kernel | * | |
linux | linux_kernel | * |
{ "configurations": [ { "nodes": [ { "cpeMatch": [ { "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "FB1C7FD1-C89E-4955-B265-456A9F757302", "versionEndExcluding": "5.15.33", "versionStartIncluding": "5.14", "vulnerable": true }, { "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "20C43679-0439-405A-B97F-685BEE50613B", "versionEndExcluding": "5.16.19", "versionStartIncluding": "5.16", "vulnerable": true }, { "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "210C679C-CF84-44A3-8939-E629C87E54BF", "versionEndExcluding": "5.17.2", "versionStartIncluding": "5.17", "vulnerable": true } ], "negate": false, "operator": "OR" } ] } ], "cveTags": [], "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix memleak in sk_psock_queue_msg\n\nIf tcp_bpf_sendmsg is running during a tear down operation we may enqueue\ndata on the ingress msg queue while tear down is trying to free it.\n\n sk1 (redirect sk2) sk2\n ------------------- ---------------\ntcp_bpf_sendmsg()\n tcp_bpf_send_verdict()\n tcp_bpf_sendmsg_redir()\n bpf_tcp_ingress()\n sock_map_close()\n lock_sock()\n lock_sock() ... blocking\n sk_psock_stop\n sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED);\n release_sock(sk);\n lock_sock()\n sk_mem_charge()\n get_page()\n sk_psock_queue_msg()\n sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED);\n drop_sk_msg()\n release_sock()\n\nWhile drop_sk_msg(), the msg has charged memory form sk by sk_mem_charge\nand has sg pages need to put. To fix we use sk_msg_free() and then kfee()\nmsg.\n\nThis issue can cause the following info:\nWARNING: CPU: 0 PID: 9202 at net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0\nCall Trace:\n \u003cIRQ\u003e\n inet_csk_destroy_sock+0x55/0x110\n tcp_rcv_state_process+0xe5f/0xe90\n ? sk_filter_trim_cap+0x10d/0x230\n ? tcp_v4_do_rcv+0x161/0x250\n tcp_v4_do_rcv+0x161/0x250\n tcp_v4_rcv+0xc3a/0xce0\n ip_protocol_deliver_rcu+0x3d/0x230\n ip_local_deliver_finish+0x54/0x60\n ip_local_deliver+0xfd/0x110\n ? ip_protocol_deliver_rcu+0x230/0x230\n ip_rcv+0xd6/0x100\n ? ip_local_deliver+0x110/0x110\n __netif_receive_skb_one_core+0x85/0xa0\n process_backlog+0xa4/0x160\n __napi_poll+0x29/0x1b0\n net_rx_action+0x287/0x300\n __do_softirq+0xff/0x2fc\n do_softirq+0x79/0x90\n \u003c/IRQ\u003e\n\nWARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0\nCall Trace:\n \u003cTASK\u003e\n __sk_destruct+0x24/0x1f0\n sk_psock_destroy+0x19b/0x1c0\n process_one_work+0x1b3/0x3c0\n ? process_one_work+0x3c0/0x3c0\n worker_thread+0x30/0x350\n ? process_one_work+0x3c0/0x3c0\n kthread+0xe6/0x110\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x22/0x30\n \u003c/TASK\u003e" }, { "lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Corregir p\u00e9rdida de memoria en sk_psock_queue_msg Si tcp_bpf_sendmsg se est\u00e1 ejecutando durante una operaci\u00f3n de desmontaje, podemos poner en cola datos en la cola de mensajes de entrada mientras el desmontaje intenta liberarlos. sk1 (redireccionar sk2) sk2 ------------------- --------------- tcp_bpf_sendmsg() tcp_bpf_send_verdict() tcp_bpf_sendmsg_redir() bpf_tcp_ingress() sock_map_close() lock_sock() lock_sock() ... bloqueando sk_psock_stop sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED); release_sock(sk); lock_sock() sk_mem_charge() get_page() sk_psock_queue_msg() sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED); drop_sk_msg() release_sock() Mientras se usa drop_sk_msg(), el mensaje ha cargado la memoria del formulario sk mediante sk_mem_charge y tiene p\u00e1ginas sg que se deben colocar. Para solucionarlo, usamos sk_msg_free() y luego kfee() msg. Este problema puede causar la siguiente informaci\u00f3n: ADVERTENCIA: CPU: 0 PID: 9202 en net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0 Rastreo de llamadas: inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xe5f/0xe90 ? sk_filter_trim_cap+0x10d/0x230 ? tcp_v4_do_rcv+0x161/0x250 tcp_v4_do_rcv+0x161/0x250 tcp_v4_rcv+0xc3a/0xce0 ip_protocol_deliver_rcu+0x3d/0x230 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0xfd/0x110 ? ip_protocol_deliver_rcu+0x230/0x230 ip_rcv+0xd6/0x100 ? ip_local_deliver+0x110/0x110 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0xa4/0x160 __napi_poll+0x29/0x1b0 net_rx_action+0x287/0x300 __do_softirq+0xff/0x2fc do_softirq+0x79/0x90 WARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0 Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 ? process_one_work+0x3c0/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 " } ], "id": "CVE-2022-49207", "lastModified": "2025-03-18T20:11:31.573", "metrics": { "cvssMetricV31": [ { "cvssData": { "attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 5.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1" }, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary" } ] }, "published": "2025-02-26T07:00:57.817", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/03948ed6553960db62f1c33bec29e64d7c191a3f" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/4dd2e947d3be13a4de3b3028859b9a6497266bcf" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/938d3480b92fa5e454b7734294f12a7b75126f09" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/ef9785f429794567792561a584901faa9291d3ee" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Analyzed", "weaknesses": [ { "description": [ { "lang": "en", "value": "CWE-401" } ], "source": "nvd@nist.gov", "type": "Primary" } ] }
Loading…
Loading…
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…