summaryrefslogtreecommitdiff
path: root/crypto
diff options
context:
space:
mode:
authorZhengchao Shao <shaozhengchao@huawei.com>2024-01-22 09:18:07 +0800
committerPaolo Abeni <pabeni@redhat.com>2024-01-23 11:21:18 +0100
commit234ec0b6034b16869d45128b8cd2dc6ffe596f04 (patch)
tree471c66a93b54bdeea58d6de1de6f77df8c24d402 /crypto
parent97de5a15edf2d22184f5ff588656030bbb7fa358 (diff)
netlink: fix potential sleeping issue in mqueue_flush_file
I analyze the potential sleeping issue of the following processes: Thread A Thread B ... netlink_create //ref = 1 do_mq_notify ... sock = netlink_getsockbyfilp ... //ref = 2 info->notify_sock = sock; ... ... netlink_sendmsg ... skb = netlink_alloc_large_skb //skb->head is vmalloced ... netlink_unicast ... sk = netlink_getsockbyportid //ref = 3 ... netlink_sendskb ... __netlink_sendskb ... skb_queue_tail //put skb to sk_receive_queue ... sock_put //ref = 2 ... ... ... netlink_release ... deferred_put_nlk_sk //ref = 1 mqueue_flush_file spin_lock remove_notification netlink_sendskb sock_put //ref = 0 sk_free ... __sk_destruct netlink_sock_destruct skb_queue_purge //get skb from sk_receive_queue ... __skb_queue_purge_reason kfree_skb_reason __kfree_skb ... skb_release_all skb_release_head_state netlink_skb_destructor vfree(skb->head) //sleeping while holding spinlock In netlink_sendmsg, if the memory pointed to by skb->head is allocated by vmalloc, and is put to sk_receive_queue queue, also the skb is not freed. When the mqueue executes flush, the sleeping bug will occur. Use vfree_atomic instead of vfree in netlink_skb_destructor to solve the issue. Fixes: c05cdb1b864f ("netlink: allow large data transfers from user-space") Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Link: https://lore.kernel.org/r/20240122011807.2110357-1-shaozhengchao@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'crypto')
0 files changed, 0 insertions, 0 deletions