Re: [LTP] thp04: Simplify to focus on CVE-2017-1000405 race test only

[linuxtestproject.agent@gmail.com]

Hi Jan,

On Tue, 21 Jul 2026, Jan Polensky wrote:
> thp04: Simplify to focus on CVE-2017-1000405 race test only

--- [PATCH 1/3] ---

> Remove ptrace mode support from thp04.c to keep the test focused on
> its original purpose: testing the CVE-2017-1000405 race condition.

The pre-patch thp04.c has no ptrace calls or "ptrace mode" branch at
all -- it is already just the plain fuzzy-sync race test using
/proc/self/mem. There does not seem to be anything to remove here.

What the diff actually does is move the static globals (write_thp,
read_thp, write_ptr, read_ptr, thp_size, writefd, readfd, fzsync_pair)
into a heap-allocated `struct thp_state *state`, and add a new probe in
setup() that performs a real write() to /proc/self/mem and reports
TCONF if it fails with EIO (i.e. when CONFIG_PROC_MEM_FORCE_PTRACE or
CONFIG_PROC_MEM_NO_FORCE blocks unforced self-writes). Could the commit
message be updated to describe this actual change and its motivation?

> The ptrace-based /proc/pid/mem write functionality is now covered by
> dedicated tests in testcases/kernel/syscalls/ptrace/:
> - ptrace12: Tests that CONFIG_PROC_MEM_FORCE_PTRACE blocks self-writes
> - ptrace13: Tests that ptrace allows parent-to-child memory writes

Neither ptrace12 nor ptrace13 exists yet at this point in the series --
they are added by patches 2/3 and 3/3. The same names are also baked
into the new TCONF message added to thp04.c's setup(). Someone
bisecting to this commit alone would see references to tests that
don't exist. Would moving this patch after the two ptrace patches (or
dropping the concrete test names) avoid the forward reference?

> +	TEST(lseek(state->writefd, (off_t)state->write_ptr, SEEK_SET));
> +	if (TST_RET == -1)
> +		tst_brk(TBROK | TTERRNO, "lseek on /proc/self/mem failed");

lseek() isn't the subject under test here -- only the write() probe
right after it is meant to observe the FOLL_FORCE policy. Since
SAFE_LSEEK() exists and this duplicates its abort-on-error behavior by
hand, could this use SAFE_LSEEK() instead?

--- [PATCH 3/3] ---

> Add ptrace13 to verify that a tracer can write to tracee memory via
> /proc/pid/mem when CONFIG_PROC_MEM_FORCE_PTRACE=y is active.

Unlike ptrace12's self-write probe (which reports TCONF whenever the
write unexpectedly succeeds), this test has no runtime or
.needs_kconfigs gate on CONFIG_PROC_MEM_FORCE_PTRACE. If the running
kernel enforces CONFIG_PROC_MEM_NO_FORCE (or is booted with
"proc_mem.force_override=never"), proc_mem_foll_force() in
fs/proc/base.c always returns false, so the write to the read-only
page in the run() loop fails with -EIO:

> 		SAFE_LSEEK(memfd, (off_t)shared->test_ptr, SEEK_SET);
> 		SAFE_WRITE(SAFE_WRITE_ALL, memfd, &write_val, sizeof(write_val));

SAFE_WRITE() aborts with TBROK on that -EIO instead of the test
reporting TCONF for a kernel that isn't configured with the "ptrace"
policy. Could this test gate on
`.needs_kconfigs = {"CONFIG_PROC_MEM_FORCE_PTRACE=y", NULL}`, or add a
runtime probe similar to the one used in ptrace12/thp04, so it reports
TCONF instead of TBROK on such kernels?

Verdict - Needs revision

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

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