CVE-2024-26676
Publication date:
02/04/2024
In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.<br />
<br />
syzbot reported a warning [0] in __unix_gc() with a repro, which<br />
creates a socketpair and sends one socket&#39;s fd to itself using the<br />
peer.<br />
<br />
socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0<br />
sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\360", iov_len=1}],<br />
msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET,<br />
cmsg_type=SCM_RIGHTS, cmsg_data=[3]}],<br />
msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1<br />
<br />
This forms a self-cyclic reference that GC should finally untangle<br />
but does not due to lack of MSG_OOB handling, resulting in memory<br />
leak.<br />
<br />
Recently, commit 11498715f266 ("af_unix: Remove io_uring code for<br />
GC.") removed io_uring&#39;s dead code in GC and revealed the problem.<br />
<br />
The code was executed at the final stage of GC and unconditionally<br />
moved all GC candidates from gc_candidates to gc_inflight_list.<br />
That papered over the reported problem by always making the following<br />
WARN_ON_ONCE(!list_empty(&gc_candidates)) false.<br />
<br />
The problem has been there since commit 2aab4b969002 ("af_unix: fix<br />
struct pid leaks in OOB support") added full scm support for MSG_OOB<br />
while fixing another bug.<br />
<br />
To fix this problem, we must call kfree_skb() for unix_sk(sk)->oob_skb<br />
if the socket still exists in gc_candidates after purging collected skb.<br />
<br />
Then, we need to set NULL to oob_skb before calling kfree_skb() because<br />
it calls last fput() and triggers unix_release_sock(), where we call<br />
duplicate kfree_skb(u->oob_skb) if not NULL.<br />
<br />
Note that the leaked socket remained being linked to a global list, so<br />
kmemleak also could not detect it. We need to check /proc/net/protocol<br />
to notice the unfreed socket.<br />
<br />
[0]:<br />
WARNING: CPU: 0 PID: 2863 at net/unix/garbage.c:345 __unix_gc+0xc74/0xe80 net/unix/garbage.c:345<br />
Modules linked in:<br />
CPU: 0 PID: 2863 Comm: kworker/u4:11 Not tainted 6.8.0-rc1-syzkaller-00583-g1701940b1a02 #0<br />
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024<br />
Workqueue: events_unbound __unix_gc<br />
RIP: 0010:__unix_gc+0xc74/0xe80 net/unix/garbage.c:345<br />
Code: 8b 5c 24 50 e9 86 f8 ff ff e8 f8 e4 22 f8 31 d2 48 c7 c6 30 6a 69 89 4c 89 ef e8 97 ef ff ff e9 80 f9 ff ff e8 dd e4 22 f8 90 0b 90 e9 7b fd ff ff 48 89 df e8 5c e7 7c f8 e9 d3 f8 ff ff e8<br />
RSP: 0018:ffffc9000b03fba0 EFLAGS: 00010293<br />
RAX: 0000000000000000 RBX: ffffc9000b03fc10 RCX: ffffffff816c493e<br />
RDX: ffff88802c02d940 RSI: ffffffff896982f3 RDI: ffffc9000b03fb30<br />
RBP: ffffc9000b03fce0 R08: 0000000000000001 R09: fffff52001607f66<br />
R10: 0000000000000003 R11: 0000000000000002 R12: dffffc0000000000<br />
R13: ffffc9000b03fc10 R14: ffffc9000b03fc10 R15: 0000000000000001<br />
FS: 0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000<br />
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br />
CR2: 00005559c8677a60 CR3: 000000000d57a000 CR4: 00000000003506f0<br />
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br />
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br />
Call Trace:<br />
<br />
process_one_work+0x889/0x15e0 kernel/workqueue.c:2633<br />
process_scheduled_works kernel/workqueue.c:2706 [inline]<br />
worker_thread+0x8b9/0x12a0 kernel/workqueue.c:2787<br />
kthread+0x2c6/0x3b0 kernel/kthread.c:388<br />
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147<br />
ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242<br />
Severity CVSS v4.0: Pending analysis
Last modification:
07/05/2025
