Re: [LTP] [PATCH] cve: add CVE-2025-38236 test

[Wei Gao via ltp <ltp@lists.linux.it>]

On Tue, Aug 12, 2025 at 10:45:59AM +0200, Andrea Cervesato wrote:
> From: Andrea Cervesato <andrea.cervesato@suse.com>
> 
> Test for CVE-2025-38236 fixed in kernel v6.16-rc4:
> af_unix: Don't leave consecutive consumed OOB skbs.
> 
> The bug is triggered by sending multiple out-of-band data to a socket and
> reading it back from it. According to the MSG_OOB implementation, this
> shouldn't be possible. When system is affected by CVE-2025-38236, instead,
> skb queue holds MSG_OOB data, breaking recv() and causing a use-after-free
> condition.
> 
> Even if MSG_OOB is mostly used inside Oracle's product, it is enabled by
> default in linux kernel via CONFIG_AF_UNIX_OOB. This is accessible via
> Chrome's renderer sandbox, which might cause an attacker to escalate and to
> obtain privileges in the system.
> 
> Signed-off-by: Andrea Cervesato <andrea.cervesato@suse.com>
> ---
>  testcases/cve/.gitignore       |   1 +
>  testcases/cve/cve-2025-38236.c | 101 +++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 102 insertions(+)
> 
> diff --git a/testcases/cve/.gitignore b/testcases/cve/.gitignore
> index 3a2b2bed619c99a592f51afe50b7196c593f1f45..8eb17ce56b01070e47917f9bb44cf146c0c5b338 100644
> --- a/testcases/cve/.gitignore
> +++ b/testcases/cve/.gitignore
> @@ -13,3 +13,4 @@ cve-2017-17053
>  cve-2022-4378
>  icmp_rate_limit01
>  tcindex01
> +cve-2025-38236
> diff --git a/testcases/cve/cve-2025-38236.c b/testcases/cve/cve-2025-38236.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..68cb3d3ee2b624df2a6de2ce07da1d1e3efc8bb8
> --- /dev/null
> +++ b/testcases/cve/cve-2025-38236.c
> @@ -0,0 +1,101 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2025 SUSE LLC Andrea Cervesato <andrea.cervesato@suse.com>
> + */
> +
> +/*\
> + * Test for CVE-2025-38236 fixed in kernel v6.16-rc4:
> + * af_unix: Don't leave consecutive consumed OOB skbs.
> + *
> + * The bug is triggered by sending multiple out-of-band data to a socket and
> + * reading it back from it. According to the MSG_OOB implementation, this
> + * shouldn't be possible. When system is affected by CVE-2025-38236, instead,
> + * skb queue holds MSG_OOB data, breaking recv() and causing a use-after-free
> + * condition.
> + *
> + * Even if MSG_OOB is mostly used inside Oracle's product, it is enabled by
> + * default in linux kernel via CONFIG_AF_UNIX_OOB. This is accessible via
> + * Chrome's renderer sandbox, which might cause an attacker to escalate and to
> + * obtain privileges in the system.
> + */
> +
> +#include "tst_test.h"
> +
> +static const struct timeval sock_timeout = {
> +	.tv_sec = 1,
> +};
> +
> +static char dummy;
> +static int sock[2];
> +
> +static void run(void)
> +{
> +	int ret;
> +
> +	dummy = '\0';
> +
> +	tst_res(TINFO, "#1 send and receive out-of-band data");
> +	SAFE_SEND(0, sock[1], "A", 1, MSG_OOB);
> +	SAFE_RECV(0, sock[0], &dummy, 1, MSG_OOB);
> +
> +	tst_res(TINFO, "#2 send and receive out-of-band data");
> +	SAFE_SEND(0, sock[1], "A", 1, MSG_OOB);
> +	SAFE_RECV(0, sock[0], &dummy, 1, MSG_OOB);
> +
> +	tst_res(TINFO, "Send out-of-band data");
> +	SAFE_SEND(0, sock[1], "A", 1, MSG_OOB);
Thanks for your patch. I have some minor comments:
1) I suggest check dummy value after each SAFE_RECV above also
2) Better send different char for different sent such as A,B,C
3) Is the second send operation necessary?
> +
> +	tst_res(TINFO, "Receive data from normal stream");
> +
> +	ret = recv(sock[0], &dummy, 1, 0);
> +	if (ret == -1) {
> +		if (errno == EWOULDBLOCK)
> +			tst_res(TPASS, "Can't read out-of-band data from normal stream");
> +		else
> +			tst_brk(TBROK | TERRNO, "recv error");
> +	} else {
> +		const char *msg = "We are able to read out-of-band data from normal stream";
> +
> +		if (dummy == 'A') {
> +			tst_res(TFAIL, "%s", msg);
> +		} else {
> +			tst_res(TFAIL, "%s, but data doesn't match: '%c' != 'A'",
> +				msg, dummy);
> +		}
> +
> +		SAFE_RECV(0, sock[0], &dummy, 1, MSG_OOB);
4) I think we need check dummy == 'A' here and then report TFAIL with
use-after-free
> +
> +		tst_res(TFAIL, "We are able to access data from skb queue (use-after-free)");
> +	}
> +}
> +
> +static void setup(void)
> +{
> +	SAFE_SOCKETPAIR(AF_UNIX, SOCK_STREAM, 0, sock);
> +	SAFE_SETSOCKOPT(sock[0], SOL_SOCKET, SO_RCVTIMEO,
> +		 &sock_timeout, sizeof(struct timeval));
> +}
> +
> +static void cleanup(void)
> +{
> +	if (sock[0] != -1)
> +		SAFE_CLOSE(sock[0]);
> +
> +	if (sock[1] != -1)
> +		SAFE_CLOSE(sock[1]);
> +}
> +
> +static struct tst_test test = {
> +	.test_all = run,
> +	.setup = setup,
> +	.cleanup = cleanup,
> +	.needs_kconfigs = (const char *[]) {
> +		"CONFIG_AF_UNIX_OOB=y",
> +		NULL
> +	},
> +	.tags = (const struct tst_tag[]) {
> +		{"linux-git", "32ca245464e1"},
> +		{"CVE", "2025-38236"},
> +		{}
> +	}
> +};
> 
> ---
> base-commit: e2c58cfcb82be0b376098a67c8f45264282be67a
> change-id: 20250812-cve_2025_38236-7cb0cd4fdbf5
> 
> Best regards,
> -- 
> Andrea Cervesato <andrea.cervesato@suse.com>
> 
> 
> -- 
> Mailing list info: https://lists.linux.it/listinfo/ltp

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp