[LTP] [PATCH] cve: add test reproducer for cve-2025-21756
Andrea Cervesato
andrea.cervesato@suse.com
Tue Sep 23 09:56:49 CEST 2025
Hi!
On 9/22/25 4:32 PM, Cyril Hrubis wrote:
> Hi!
>> +/*\
>> + * Test for CVE-2025-21756 fixed in kernel v6.14:
>> + * fcdd2242c023 vsock: Keep the binding until socket destruction
>> + *
>> + * Reproducer based on:
>> + *https://lore.kernel.org/all/20250128-vsock-transport-vs-autobind-v3-5-1cf57065b770@rbox.co/
>> + *
>> + * Beware, this test will crash the system.
>> + */
>> +
>> +#include "tst_test.h"
>> +
>> +#if HAVE_LINUX_VM_SOCKETS_H
>> +
>> +#include "lapi/vm_sockets.h"
> Do we need the #if HAVE_LINUX_VM_SOCKETS_H if we include lapi/ fallback?
Yes we do need a struct sockaddr_vm fallback definition in LTP.
>
>> +#define MAX_PORT_RETRIES 24
>> +#define VMADDR_CID_NONEXISTING 42
>> +
>> +static int vsock_bind(unsigned int cid, unsigned int port, int type)
>> +{
>> + int sock;
>> +
>> + struct sockaddr_vm sa = {
>> + .svm_family = AF_VSOCK,
>> + .svm_cid = cid,
>> + .svm_port = port,
>> + };
>> +
>> + sock = SAFE_SOCKET(AF_VSOCK, type, 0);
>> + SAFE_BIND(sock, (struct sockaddr *)&sa, sizeof(sa));
> I guess that with the lapi fallback we should TCONF here on ENOSYS
> instead and drop the #if at the top.
>
> Other than that the rest looks good.
>
> -- Cyril Hrubis chrubis@suse.cz
I just realized that the test is not always producing a system crash. I
tested the cve inside a VM and obtained a crash _but_ the following
dmesg error:
[ 1.282984] ------------[ cut here ]------------
[ 1.283509] refcount_t: underflow; use-after-free.
[ 1.284049] WARNING: CPU: 4 PID: 205 at lib/refcount.c:28
refcount_warn_saturate+0xd0/0x130
[ 1.284944] Modules linked in:
[ 1.285282] CPU: 4 UID: 0 PID: 205 Comm: cve-2025-21756 Tainted: G
W 6.13.0-virtme #43
[ 1.286251] Tainted: [W]=WARN
[ 1.286593] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 1.287187] RIP: 0010:refcount_warn_saturate+0xd0/0x130
[ 1.287751] Code: 0b 90 90 e9 62 76 75 00 80 3d 10 54 44 01 00 0f 85
75 ff ff ff c6 05 03 54 44 01 01 90 48 c7 c7 80 c1 ca ac e8 11 be b8 ff
90 <0f> 0b 90 90 e9 37 76 75 00 80 3d e6 53 44 01 00 0f 85 4a ff ff ff
[ 1.289682] RSP: 0018:ffffb2fec051fe60 EFLAGS: 00010282
[ 1.290228] RAX: 0000000000000000 RBX: ffff90f4c7e50000 RCX:
0000000000000000
[ 1.290987] RDX: 0000000000000000 RSI: ffffb2fec051fd00 RDI:
0000000000000001
[ 1.291741] RBP: ffff90f4c7e50000 R08: 00000000ffffdfff R09:
0000000000000001
[ 1.292501] R10: 00000000ffffdfff R11: ffffffffad076b20 R12:
ffffffffac9483c0
[ 1.293249] R13: 0000000000000000 R14: ffff90f4c925cf00 R15:
0000000000000000
[ 1.294017] FS: 00007f26beb6a740(0000) GS:ffff90f4feb00000(0000)
knlGS:0000000000000000
[ 1.294863] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.295479] CR2: 0000000000439190 CR3: 0000000007d92000 CR4:
0000000000350ef0
[ 1.296216] Call Trace:
[ 1.296501] <TASK>
[ 1.296734] ? refcount_warn_saturate+0xd0/0x130
[ 1.297221] ? __warn.cold+0xb0/0x10c
[ 1.297634] ? refcount_warn_saturate+0xd0/0x130
[ 1.298118] ? report_bug+0xd8/0x150
[ 1.298536] ? handle_bug+0x54/0x90
[ 1.298959] ? exc_invalid_op+0x17/0x70
[ 1.299531] ? asm_exc_invalid_op+0x1a/0x20
[ 1.299978] ? refcount_warn_saturate+0xd0/0x130
[ 1.300523] vsock_remove_bound+0x92/0xa0
[ 1.300955] __vsock_release+0x19a/0x1c0
[ 1.301405] vsock_release+0x32/0x50
[ 1.301798] __sock_release+0x3d/0xb0
[ 1.302197] sock_close+0x15/0x20
[ 1.302584] __fput+0xd9/0x290
[ 1.302911] __x64_sys_close+0x3c/0x80
[ 1.303317] do_syscall_64+0x9e/0x1a0
[ 1.303726] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 1.304255] RIP: 0033:0x7f26bec0503a
[ 1.304655] Code: 08 03 00 00 59 5e 48 83 f8 fc 75 1e 83 e2 39 83 fa
08 75 16 e8 15 ff ff ff 0f 1f 80 00 00 00 00 49 89 ca 48 8b 44 24 20 0f
05 <48> 83 c4 18 c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f
[ 1.307800] RSP: 002b:00007ffe2f62e4e0 EFLAGS: 00000202 ORIG_RAX:
0000000000000003
[ 1.308618] RAX: ffffffffffffffda RBX: 00007ffe2f62e5ec RCX:
00007f26bec0503a
[ 1.309389] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
0000000000000003
[ 1.310143] RBP: 0000000000000003 R08: 0000000000000000 R09:
0000000000000000
[ 1.310903] R10: 0000000000000000 R11: 0000000000000202 R12:
0000000000424038
[ 1.311682] R13: 000000000000004c R14: 0000000000000000 R15:
0000000000000000
[ 1.312462] </TASK>
[ 1.312708] ---[ end trace 0000000000000000 ]---
I guess we need to verify that, if system is not crashed, we should
check kernel messages in order to find any error. Is there a smart way
to do it? I could parse data via FILE_LINES_SCANF() macro, but that
would require multiple iterations. The alternative is just to parse the
entire /dev/kmsg via read() and to find:
1. use-after-free message
2. test name after it
3. failing syscall vsock_release
WDYT? Maybe there are better ways to do it.
- Andrea
More information about the ltp
mailing list