CVE-2022-49209

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full<br /> <br /> If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()<br /> returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial<br /> memory has been alloced by sk_msg_alloc(), that is, msg_tx-&gt;sg.size is<br /> greater than osize after sk_msg_alloc(), memleak occurs. To fix we use<br /> sk_msg_trim() to release the allocated memory, then goto wait for memory.<br /> <br /> Other call paths of sk_msg_alloc() have the similar issue, such as<br /> tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),<br /> as Cong Wang suggested.<br /> <br /> This issue can cause the following info:<br /> WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0<br /> Call Trace:<br /> <br /> inet_csk_destroy_sock+0x55/0x110<br /> __tcp_close+0x279/0x470<br /> tcp_close+0x1f/0x60<br /> inet_release+0x3f/0x80<br /> __sock_release+0x3d/0xb0<br /> sock_close+0x11/0x20<br /> __fput+0x92/0x250<br /> task_work_run+0x6a/0xa0<br /> do_exit+0x33b/0xb60<br /> do_group_exit+0x2f/0xa0<br /> get_signal+0xb6/0x950<br /> arch_do_signal_or_restart+0xac/0x2a0<br /> exit_to_user_mode_prepare+0xa9/0x200<br /> syscall_exit_to_user_mode+0x12/0x30<br /> do_syscall_64+0x46/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> <br /> WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260<br /> Call Trace:<br /> <br /> __sk_destruct+0x24/0x1f0<br /> sk_psock_destroy+0x19b/0x1c0<br /> process_one_work+0x1b3/0x3c0<br /> kthread+0xe6/0x110<br /> ret_from_fork+0x22/0x30<br />