CVE-2024-47711: af_unix: Don't return OOB skb in manage_oob().
In the Linux kernel, the following vulnerability has been resolved:
afunix: Don't return OOB skb in manageoob().
syzbot reported use-after-free in unixstreamrecvurg(). [0]
The scenario is
1. send(MSGOOB) 2. recv(MSGOOB) -> The consumed OOB remains in recv queue 3. send(MSGOOB) 4. recv() -> manageoob() returns the next skb of the consumed OOB -> This is also OOB, but unixsk(sk)->oobskb is not cleared 5. recv(MSGOOB) -> unixsk(sk)->oobskb is used but already freed
The recent commit 8594d9b85c07 ("afunix: Don't call skbget() for OOB skb.") uncovered the issue.
If the OOB skb is consumed and the next skb is peeked in manageoob(), we still need to check if the skb is OOB.
Let's do so by falling back to the following checks in manageoob() and add the test case in selftest.
Note that we need to add a similar check for SIOCATMARK.
[0]: BUG: KASAN: slab-use-after-free in unixstreamreadactor+0xa6/0xb0 net/unix/afunix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235
CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> dumpstack lib/dumpstack.c:93 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:119 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 unixstreamreadactor+0xa6/0xb0 net/unix/afunix.c:2959 unixstreamrecvurg+0x1df/0x320 net/unix/afunix.c:2640 unixstreamreadgeneric+0x2456/0x2520 net/unix/afunix.c:2778 unixstreamrecvmsg+0x22b/0x2c0 net/unix/afunix.c:2996 sockrecvmsgnosec net/socket.c:1046 [inline] sockrecvmsg+0x22f/0x280 net/socket.c:1068 sysrecvmsg+0x1db/0x470 net/socket.c:2816 sysrecvmsg net/socket.c:2858 [inline] sysrecvmsg+0x2f0/0x3e0 net/socket.c:2888 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIGRAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 </TASK>
Allocated by task 5235: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 unpoisonslabobject mm/kasan/common.c:312 [inline] kasanslaballoc+0x66/0x80 mm/kasan/common.c:338 kasanslaballoc include/linux/kasan.h:201 [inline] slabpostallochook mm/slub.c:3988 [inline] slaballocnode mm/slub.c:4037 [inline] kmemcacheallocnodenoprof+0x16b/0x320 mm/slub.c:4080 allocskb+0x1c3/0x440 net/core/skbuff.c:667 allocskb include/linux/skbuff.h:1320 [inline] allocskbwithfrags+0xc3/0x770 net/core/skbuff.c:6528 sockallocsendpskb+0x91a/0xa60 net/core/sock.c:2815 sockallocsendskb include/net/sock.h:1778 [inline] queueoob+0x108/0x680 net/unix/afunix.c:2198 unixstreamsendmsg+0xd24/0xf80 net/unix/afunix.c:2351 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x221/0x270 net/socket.c:745 syssendmsg+0x525/0x7d0 net/socket.c:2597 syssendmsg net/socket.c:2651 [inline] syssendmsg+0x2b0/0x3a0 net/socket.c:2680 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f
Freed by task 5235: kasansavestack mm/kasan/common.c:47 ---truncated---
Other sources
This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.
— Launchpad
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 5.10.223-1Fixed in 5.10.234-1Fixed in 6.1.129-1Fixed in 6.1.135-1Fixed in 6.12.25-1Fixed in 6.12.27-1 - Configuration
Patch af_unix: change manage_oob() to stop returning the OOB skb (as indicated by the resolved issue text: "af_unix: Don't return OOB skb in manage_oob()").
Linux kernel af_unix manage_oob() OOB skb handling = Do not return OOB skb in manage_oob() - Configuration
Update manage_oob() logic to include a similar OOB skb check for SIOCATMARK ("Note that we need to add a similar check for SIOCATMARK").
Linux kernel af_unix SIOCATMARK OOB check = Add similar check for SIOCATMARK in manage_oob() - Compensating control
Run/extend the Linux kernel selftests by adding the described test case in selftest for the OOB handling regression ("add the test case in selftest").
Event History
Frequently Asked Questions
What is the severity of CVE-2024-47711?
CVE-2024-47711 has a high severity rating due to its potential for exploit and impact on the Linux kernel's stability.
How do I fix CVE-2024-47711?
To fix CVE-2024-47711, update your Linux kernel to a version that includes the patches addressing this vulnerability.
What products are affected by CVE-2024-47711?
CVE-2024-47711 affects versions of the Linux kernel from 6.9.8 to 6.10 and 6.10 to 6.11.2.
What does CVE-2024-47711 involve?
CVE-2024-47711 involves a use-after-free vulnerability in the Linux kernel's handling of out-of-band data.
How can I determine if my system is vulnerable to CVE-2024-47711?
You can determine if your system is vulnerable to CVE-2024-47711 by checking your Linux kernel version against the affected versions.