[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