[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