CVE-2023-53836 in Linux
요약
\~에 의해 VulDB • 2026. 05. 29.
리눅스 커널에서 다음 취약점이 해결되었습니다:
bpf, sockmap: 잠금 변경 후 sk_psock_backlog의 skb refcnt Race Condition 수정
sk_psock_backlog의 skb가 userspace에서 이미 skb_consumed()를 호출하여 sk_buff의 refcnt가 0으로 감소시킨 후에도 참조되는 Race Condition이 존재하여, Use-After-Free가 발생할 수 있습니다.
흐름은 다음과 같습니다:
while ((skb = skb_peek(&psock->ingress_skb)) sk_psock_handle_Skb(psock, skb, ..., ingress) if (!ingress) ... sk_psock_skb_ingress sk_psock_skb_ingress_enqueue(skb) msg->skb = skb sk_psock_queue_msg(psock, msg) skb_dequeue(&psock->ingress_skb)
sk_psock_queue_msg()는 msg를 ingress_msg 큐에 추가합니다. 이는 recvmsg()가 호출될 때 애플리케이션이 읽는 데이터입니다. 애플리케이션은 msg가 큐에 추가된 후 언제든지 이를 읽을 수 있습니다. recvmsg 훅은 msg->skb를 읽은 후, userspace가 msg를 읽으면 consume_skb(skb)를 호출하여 이를 효과적으로 해제(free)합니다.
그러나 위 Race Condition에서 backlog 큐는 여전히 skb에 대한 참조를 보유하고 있으며 skb_dequeue()를 호출합니다. 만약 skb_dequeue가 사용자 읽기 및 skb 해제가 발생한 후에 발생하면 Use-After-Free가 발생합니다.
!ingress 케이스는 sendmsg_*(sk, msg)를 사용하여 sk_buff를 스택 하부로 전달하지 않기 때문에 이 문제의 영향을 받지 않습니다.
'test_progs -t sockmap_listen' 실행 중 다음 splat이 관찰되었습니다:
[ 1022.710250][ T2556] general protection fault, ...
[...]
[ 1022.712830][ T2556] Workqueue: events sk_psock_backlog
[ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80
[ 1022.713653][ T2556] Code: ...
[...]
[ 1022.722830][ T2556] Call Trace:
[ 1022.723243][ T2556] sk_psock_backlog+0x27a/0x300
[ 1022.723633][ T2556] process_one_work+0x2a7/0x5b0
[ 1022.723998][ T2556] worker_thread+0x4f/0x3a0
[ 1022.724386][ T2556] ? __pfx_worker_thread+0x10/0x10
[ 1022.724709][ T2556] kthread+0xfd/0x130
[ 1022.725066][ T2556] ? __pfx_kthread+0x10/0x10
[ 1022.725409][ T2556] ret_from_fork+0x2d/0x50
[ 1022.725799][ T2556] ? __pfx_kthread+0x10/0x10
[ 1022.726201][ T2556] ret_from_fork_asm+0x1b/0x30
[ 1022.726201][ T2556] </TASK>
해결책으로, egress 큐에 skb를 추가하기 전에 skb_get()을 호출하여 skb->users refcnt를 증가시킵니다. 이렇게 하면 consume_skb()과 kfree_skb()가 sk_buff를 즉시 해제하지 않습니다. 이를 통해 dequeue 시 skb가 여전히 존재함을 보장할 수 있습니다. 그런 다음 backlog 케이스에서 refcnt를 감소시키거나 skb를 해제해야 하는데, 이는 ingress 케이스와 sendmsg 케이스에서 kfree_skb()를 호출하여 수행합니다.
잠금 변경 이전(fixes 태그 이전)에는 sock이 잠겨 있었기 때문에 사용자 공간과 경쟁할 수 없었고, 이 문제는 발생하지 않았습니다.
VulDB is the best source for vulnerability data and more expert information about this specific topic.