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

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

[Andrea Cervesato]

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);
+
+	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);
+
+		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

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

[Wei Gao via ltp]

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

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

[Petr Vorel]

Hi Andrea,

>  testcases/cve/.gitignore       |   1 +
>  testcases/cve/cve-2025-38236.c | 101 +++++++++++++++++++++++++++++++++++++++++

File not added into runtest/cve.

Maybe we need to enhance 'make check' to check this via 'git grep'.

checkpatch.pl looks into resulted file, IMHO we have no tool to check the patch
itself. But maybe enhance b4 (kind of plugin) to check this :).

Kind regards,
Petr

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

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

[Petr Vorel]

Hi Andrea,

> +++ 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.

Maybe mention it's based on the reproducer from
https://project-zero.issues.chromium.org/issues/423023990

(That adds both background info + kind of credit of the author of the patch who
was the author of the initial reproducer).

> + */
> +
> +#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);
> +
> +	tst_res(TINFO, "Receive data from normal stream");
> +
> +	ret = recv(sock[0], &dummy, 1, 0);

+1 the core part from the original verifier.

> +	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 {
very nit: using 'if' with return is more readable than short 'if' part and long
'else' part:

if (...) {
	...
	return;
}

const char *msg = "We are able to read out-of-band data from normal stream";
...


> +		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);

FYI: on vulnerable kernel with SELinux I get (nothing to be fixed):
cve-2025-38236.c:48: TINFO: Receive data from normal stream
cve-2025-38236.c:60: TFAIL: We are able to read out-of-band data from normal stream
cve-2025-38236.c:66: TBROK: recv(3, 0x4391d8, 1, 1) failed: EFAULT (14)
> +
> +		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));
> +}

Why is struct timeval needed? I haven't found that in
https://project-zero.issues.chromium.org/issues/423023990
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=32ca245464e1

and test works as a verifier without it. If really not needed please remove it
before merge.

> +
> +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",
Although this is true I wonder if we should limit the reproducer to this.
If one day config silently renames / is removed (but OOB kept) the reproducer
will be lost.

LGTM, thanks for a quickly porting the reproducer!

With added entry to runtest/cve you may add:
Reviewed-by: Petr Vorel <pvorel@suse.cz>

Kind regards,
Petr

> +		NULL
> +	},
> +	.tags = (const struct tst_tag[]) {
> +		{"linux-git", "32ca245464e1"},
> +		{"CVE", "2025-38236"},
> +		{}
> +	}
> +};

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

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

[Andrea Cervesato via ltp]

Hi,

On 8/12/25 12:51 PM, Petr Vorel wrote:
> Hi Andrea,
>
>> +++ 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.
> Maybe mention it's based on the reproducer from
> https://project-zero.issues.chromium.org/issues/423023990
>
> (That adds both background info + kind of credit of the author of the patch who
> was the author of the initial reproducer).
>
>> + */
>> +
>> +#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);
>> +
>> +	tst_res(TINFO, "Receive data from normal stream");
>> +
>> +	ret = recv(sock[0], &dummy, 1, 0);
> +1 the core part from the original verifier.
>
>> +	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 {
> very nit: using 'if' with return is more readable than short 'if' part and long
> 'else' part:
>
> if (...) {
> 	...
> 	return;
> }
>
> const char *msg = "We are able to read out-of-band data from normal stream";
> ...
>
>
>> +		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);
> FYI: on vulnerable kernel with SELinux I get (nothing to be fixed):
> cve-2025-38236.c:48: TINFO: Receive data from normal stream
> cve-2025-38236.c:60: TFAIL: We are able to read out-of-band data from normal stream
> cve-2025-38236.c:66: TBROK: recv(3, 0x4391d8, 1, 1) failed: EFAULT (14)
Maybe we can verify at the beginning is SELinux is enabled. I don't know...
>> +
>> +		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));
>> +}
> Why is struct timeval needed? I haven't found that in
> https://project-zero.issues.chromium.org/issues/423023990
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=32ca245464e1
>
> and test works as a verifier without it. If really not needed please remove it
> before merge.
We need to set a timeout for recv(), otherwise it will stuck on systems 
which are not bugged.
>> +
>> +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",
> Although this is true I wonder if we should limit the reproducer to this.
> If one day config silently renames / is removed (but OOB kept) the reproducer
> will be lost.
That's valid in general, I can remove it but I don't know if it makes 
much sense, considering that feature something which is nowadays 
disabled in many systems due to this bug.
>
> LGTM, thanks for a quickly porting the reproducer!
>
> With added entry to runtest/cve you may add:
Forgot, thanks
> Reviewed-by: Petr Vorel <pvorel@suse.cz>
>
> Kind regards,
> Petr
>
>> +		NULL
>> +	},
>> +	.tags = (const struct tst_tag[]) {
>> +		{"linux-git", "32ca245464e1"},
>> +		{"CVE", "2025-38236"},
>> +		{}
>> +	}
>> +};
Andrea

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

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

[Andrea Cervesato via ltp]

Hi,

On 8/12/25 11:43 AM, Wei Gao wrote:
> 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
This is not useful because bug is triggered after the second send()
> 2) Better send different char for different sent such as A,B,C
This can be done
> 3) Is the second send operation necessary?
Yes (comment above)
>> +
>> +	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
- Andrea

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

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

[Petr Vorel]

Hi Andrea, Wei,

...
> > 1) I suggest check dummy value after each SAFE_RECV above also
> This is not useful because bug is triggered after the second send()
> > 2) Better send different char for different sent such as A,B,C

+1, very good point. While the original C reproducer from Jann Horn in chromium
[1] used the same char "A", the pythonized reproducer from the kernel fix author
Kuniyuki Iwashima used a different chars. Obviously debugging the fix it was
easier with different chars :).

Kind regards,
Petr

[1] https://project-zero.issues.chromium.org/issues/423023990
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=32ca245464e1

> This can be done

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

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

[Cyril Hrubis]

Hi!
> >  testcases/cve/.gitignore       |   1 +
> >  testcases/cve/cve-2025-38236.c | 101 +++++++++++++++++++++++++++++++++++++++++
> 
> File not added into runtest/cve.
> 
> Maybe we need to enhance 'make check' to check this via 'git grep'.
> 
> checkpatch.pl looks into resulted file, IMHO we have no tool to check the patch
> itself. But maybe enhance b4 (kind of plugin) to check this :).

Or we can genereate the cve runtest file. It should be possible to build
it from the metadata during the build.

-- 
Cyril Hrubis
chrubis@suse.cz

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

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

[Cyril Hrubis]

Hi!
> We need to set a timeout for recv(), otherwise it will stuck on systems 
> which are not bugged.

Or just pass MSG_DONTWAIT to the recv()?

-- 
Cyril Hrubis
chrubis@suse.cz

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

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

[Andrea Cervesato via ltp]

On 8/12/25 1:14 PM, Cyril Hrubis wrote:
> Hi!
>> We need to set a timeout for recv(), otherwise it will stuck on systems
>> which are not bugged.
> Or just pass MSG_DONTWAIT to the recv()?
>
This is a good idea. I will add this

- Andrea


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

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

[Petr Vorel]

Hi Andrea,

...
> > > +		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);
> > FYI: on vulnerable kernel with SELinux I get (nothing to be fixed):
> > cve-2025-38236.c:48: TINFO: Receive data from normal stream
> > cve-2025-38236.c:60: TFAIL: We are able to read out-of-band data from normal stream
> > cve-2025-38236.c:66: TBROK: recv(3, 0x4391d8, 1, 1) failed: EFAULT (14)
> Maybe we can verify at the beginning is SELinux is enabled. I don't know...

I would not do that. I'm not sure if SELinux mitigates the problem (IMHO not)
and on fixed kernel (also with SELinux) recv() works:

cve-2025-38236.c:53: TPASS: Can't read out-of-band data from normal stream

It's just a note that it's different. Fortunately there is also TFAIL,
thus it's obvious kernel is vulnerable.

And again, there is the trap with LSM modules: what about the others? At least
AppArmor (still widely used, although less than SELinux).

Tested-by: Petr Vorel <pvorel@suse.cz>

> > > +
> > > +		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));
> > > +}
> > Why is struct timeval needed? I haven't found that in
> > https://project-zero.issues.chromium.org/issues/423023990
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=32ca245464e1

> > and test works as a verifier without it. If really not needed please remove it
> > before merge.
> We need to set a timeout for recv(), otherwise it will stuck on systems
> which are not bugged.

Indeed.

...
> > > +static struct tst_test test = {
> > > +	.test_all = run,
> > > +	.setup = setup,
> > > +	.cleanup = cleanup,
> > > +	.needs_kconfigs = (const char *[]) {
> > > +		"CONFIG_AF_UNIX_OOB=y",
> > Although this is true I wonder if we should limit the reproducer to this.
> > If one day config silently renames / is removed (but OOB kept) the reproducer
> > will be lost.
> That's valid in general, I can remove it but I don't know if it makes much
> sense, considering that feature something which is nowadays disabled in many
> systems due to this bug.

Fair enough. More important is that MSG_OOB most certainly require
CONFIG_AF_UNIX_OOB, so it's probably correct to have it.

Kind regards,
Petr

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

[LTP] [doc, runtest] [was: Re: [PATCH] cve: add CVE-2025-38236 test]

[Petr Vorel]

Hi Cyril, all,

> Hi!
> > >  testcases/cve/.gitignore       |   1 +
> > >  testcases/cve/cve-2025-38236.c | 101 +++++++++++++++++++++++++++++++++++++++++

> > File not added into runtest/cve.

> > Maybe we need to enhance 'make check' to check this via 'git grep'.

> > checkpatch.pl looks into resulted file, IMHO we have no tool to check the patch
> > itself. But maybe enhance b4 (kind of plugin) to check this :).

> Or we can genereate the cve runtest file. It should be possible to build
> it from the metadata during the build.

This problem happen on all runtest files, fixing just one does not fix the
problem.

Sure, it'd be possible to generate runtest/cve from metadata. Do we really want
to implement it? (I can create a ticket). I guess we would use C and ujson to
not require json-c or python3 for building LTP.

I would be more interested to have section "CVE reproducers" in Statistics page [1].
While the same tool could be used to do both goals, when only doc page
implemented, it could be easily done in python3 (doc/conf.py already parses
ltp.json).

When we are at Statistics page, also generating list of reproducers (based on
kernel fixes) would be also nice. Because this was implemented in the previous
asciidoctor implementation. How about having these lists Statistics, where are
other tables already (and linking each test to "Test Catalog")?

Also I find "Statistics" name confusing. It says nothing about the content. I
wonder if people curiously click on the page or just ignore the page (if they
don't like math :)). Maybe "Kernel coverage" or something like that would be
more informative.

Kind regards,
Petr

[1] https://linux-test-project.readthedocs.io/en/latest/users/stats.html

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

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

[Petr Vorel]

> Hi!
> > We need to set a timeout for recv(), otherwise it will stuck on systems 
> > which are not bugged.

> Or just pass MSG_DONTWAIT to the recv()?

+1, that works.

Kind regards,
Petr

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

Re: [LTP] [doc, runtest] [was: Re: [PATCH] cve: add CVE-2025-38236 test]

[Cyril Hrubis]

Hi!
> This problem happen on all runtest files, fixing just one does not fix the
> problem.

Well we can do that for any runtest file that has clear definition of
which tests belongs there. For CVE it's crystal clear, tests that have
cve tag should be there. For the rest of the runtest files, it's not so
much. Maybe for syscalls we may be able to do so.

The main thing is that we have to start somewhere got eventually get
there. I just quickly looked at the cve runtest file and figured out
that we have to add tests variants somewhere into the metadata. I.e.
quite a few of the CVE tests have command line options in the runtest
file which has to be stored somewhere else.

> Sure, it'd be possible to generate runtest/cve from metadata. Do we really want
> to implement it? (I can create a ticket). I guess we would use C and ujson to
> not require json-c or python3 for building LTP.

Or we can hook it up directly into the metadata parser, instead of
parsing the resulting JSON we can act on the data while they are in the
memory. Matching some tags and writing a test name into a file could be
easily done.

> I would be more interested to have section "CVE reproducers" in Statistics page [1].
> While the same tool could be used to do both goals, when only doc page
> implemented, it could be easily done in python3 (doc/conf.py already parses
> ltp.json).
> 
> When we are at Statistics page, also generating list of reproducers (based on
> kernel fixes) would be also nice. Because this was implemented in the previous
> asciidoctor implementation. How about having these lists Statistics, where are
> other tables already (and linking each test to "Test Catalog")?
> 
> Also I find "Statistics" name confusing. It says nothing about the content. I
> wonder if people curiously click on the page or just ignore the page (if they
> don't like math :)). Maybe "Kernel coverage" or something like that would be
> more informative.

I would put the list of reproducers and list of CVE reproducers into a
separate page that would be have "reproducers" in the name.

And statistics is probably okayish name, since coverage may mislead
people even more. For example we have a lot of tests for a write()
syscall yet coverage for all the possible write handlers in kernel is
very poor and not likely to improve.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] [doc, runtest] [was: Re: [PATCH] cve: add CVE-2025-38236 test]

[Petr Vorel]

Hi Cyril, all,

> Hi!
> > This problem happen on all runtest files, fixing just one does not fix the
> > problem.

> Well we can do that for any runtest file that has clear definition of
> which tests belongs there. For CVE it's crystal clear, tests that have
> cve tag should be there. For the rest of the runtest files, it's not so
> much. Maybe for syscalls we may be able to do so.

> The main thing is that we have to start somewhere got eventually get
> there. I just quickly looked at the cve runtest file and figured out
> that we have to add tests variants somewhere into the metadata. I.e.
> quite a few of the CVE tests have command line options in the runtest
> file which has to be stored somewhere else.

Thanks for analysis. I put your investigation into an issue:

https://github.com/linux-test-project/ltp/issues/1253

> > Sure, it'd be possible to generate runtest/cve from metadata. Do we really want
> > to implement it? (I can create a ticket). I guess we would use C and ujson to
> > not require json-c or python3 for building LTP.

> Or we can hook it up directly into the metadata parser, instead of
> parsing the resulting JSON we can act on the data while they are in the
> memory. Matching some tags and writing a test name into a file could be
> easily done.

> > I would be more interested to have section "CVE reproducers" in Statistics page [1].
> > While the same tool could be used to do both goals, when only doc page
> > implemented, it could be easily done in python3 (doc/conf.py already parses
> > ltp.json).

> > When we are at Statistics page, also generating list of reproducers (based on
> > kernel fixes) would be also nice. Because this was implemented in the previous
> > asciidoctor implementation. How about having these lists Statistics, where are
> > other tables already (and linking each test to "Test Catalog")?

> > Also I find "Statistics" name confusing. It says nothing about the content. I
> > wonder if people curiously click on the page or just ignore the page (if they
> > don't like math :)). Maybe "Kernel coverage" or something like that would be
> > more informative.

> I would put the list of reproducers and list of CVE reproducers into a
> separate page that would be have "reproducers" in the name.

https://github.com/linux-test-project/ltp/issues/1254

> And statistics is probably okayish name, since coverage may mislead
> people even more. For example we have a lot of tests for a write()
> syscall yet coverage for all the possible write handlers in kernel is
> very poor and not likely to improve.

Fair enough.

Kind regards,
Petr

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