[LTP] Add test for CVE 2026-53362

[Andrea Cervesato]

Hi Martin,

> This high-level description block opens with a plain `/*` instead of
> `/*\`. setsockopt10.c (and the rest of the test suite) uses `/*\` for
> this block, since it gets exported into the RST-based test catalog.
> 
> As written, this stays a regular comment and will not show up in the
> generated documentation. Could this be changed to `/*\`?

This is correct.

> 
> > +	/* Splice input pipe buffer page into socket */
> > +	memset(buf, 0, TEST_MSGSIZE);
> > +	buf[TEST_MSGSIZE - 6] = 1;
> > +	SAFE_WRITE(SAFE_WRITE_ALL, pipefds[1][1], buf, TEST_MSGSIZE);
> > +	splice(pipefds[1][0], NULL, sockfd, NULL, TEST_MSGSIZE, SPLICE_F_MORE);
> > +	tee(pipefds[0][0], pipefds[1][1], PATTERN_SIZE, 0);
> > +	splice(pipefds[1][0], NULL, sockfd, NULL, PATTERN_SIZE, SPLICE_F_MORE);
> 
> The file already includes "lapi/splice.h", which provides
> `SAFE_SPLICE()`. Both splice() calls here use the bare syscall
> instead, so their return value is discarded. If either call fails or
> returns short, the reproduction sequence silently doesn't happen and
> the iteration would just report TPASS without having exercised
> anything. Would SAFE_SPLICE() be preferable here?

mmmh is this the case where splice() is supposed to fail but triggering
the CVE into the kernel? if so, we probably need to add a short comment
so we know that SAFE_SPLICE() is not a good choice.

> 
> > +	for (i = 0; i < PIPE_COUNT; i++) {
> > +		SAFE_CLOSE(pipefds[i][0]);
> > +		SAFE_CLOSE(pipefds[i][1]);
> > +	}
> 
> pipefds[][] (and sockfd, closed a few lines above) are not reset to -1
> after being closed here; only setup() initializes them to -1, once.
> cleanup() decides whether a descriptor needs closing with a `>= 0`
> check.
> 
> Since leak_pipe() runs in a loop (up to 64 times), if SAFE_PIPE() or
> SAFE_SOCKET() at the start of a later iteration fails (pipe(2)/
> socket(2) can fail with EMFILE/ENFILE/ENOMEM) before refreshing a
> given slot, cleanup() would see the stale, already-closed descriptor
> number from the previous iteration as still open and try to close it
> again. Would it make sense to reset the relevant slot to -1 right
> after each close?

Again, I updated the agent but it's still asking for this. Please ignore
it, I will need to update the agent in a proper way. There's probably
some logic flaw in the rules at the moment.

Thanks,
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com