[LTP] thp04: Fix PTRACE mode for CONFIG_PROC_MEM_FORCE_PTRACE=y

[linuxtestproject.agent@gmail.com]

Hi Jan,

On Fri, 12 Jun 2026 19:17:07 +0200, Jan Polensky wrote:
> thp04: Fix PTRACE mode for CONFIG_PROC_MEM_FORCE_PTRACE=y

> -	fzsync_pair.exec_loops = 100000;
> -	tst_fzsync_pair_init(&fzsync_pair);
> +	child->readfd = SAFE_OPEN("/proc/self/mem", O_RDWR);
> +	child->fzsync_pair.exec_loops = 1000;
> +	tst_fzsync_pair_init(&child->fzsync_pair);

> +	/* In PROC_MEM_ALWAYS mode, child does writes itself */
> +	if (proc_mem_mode == PROC_MEM_ALWAYS) {
> +
> +		/* Simplified test loop without thread */
> +		for (i = 0; i < 1000; i++) {
> +			/* Write via /proc/self/mem */
> +			SAFE_LSEEK(child->writefd, (off_t)child->write_ptr, SEEK_SET);
> +			SAFE_WRITE(SAFE_WRITE_ALL, child->writefd, &c, sizeof(int));
> +
> +			/* Call madvise on write page */
> +			madvise(child->write_thp, child->thp_size, MADV_DONTNEED);
> +
> +			/* Call madvise on read page */
> +			madvise(child->read_thp, child->thp_size, MADV_DONTNEED);
> +
> +			/* Check if read page was polluted */
> +			if (*child->read_ptr != 0) {
> +				tst_res(TFAIL, "Huge zero page was polluted");
> +				return;
> +			}
> +
> +			usleep(100);
> +		}

The original test used tst_fzsync to race the /proc/self/mem write
against madvise(MADV_DONTNEED) in a separate thread. That race is
the mechanism that triggers CVE-2017-1000405: the kernel must
handle the COW fault concurrently with page reclaim to corrupt
the huge zero page.

This replacement runs write, madvise, and check sequentially in a
single thread with no concurrency. The vulnerability cannot be
triggered without the race, so the test becomes a no-op for
detecting the bug in PROC_MEM_ALWAYS mode (the default on most
systems).

The fzsync_pair is still initialized and cleaned up but never
actually used for racing (no tst_fzsync_run_a/b calls), and
readfd is opened but never read from. These are dead remnants of
the removed race mechanism.

Could the fuzzy sync race be preserved for the PROC_MEM_ALWAYS
path while adding the new write-stop-continue cycle only for the
PROC_MEM_PTRACE path?

> +	proc_mem_mode = PROC_MEM_ALWAYS;
> +	child_setup();
> +
> +	TEST(lseek(child->writefd, (off_t)child->write_ptr, SEEK_SET));
> +	if (TST_RET == -1)
> +		tst_brk(TBROK | TTERRNO, "lseek on /proc/self/mem failed");
> +
> +	TEST(write(child->writefd, &test_val, sizeof(test_val)));
> +
> +	if (TST_RET == sizeof(test_val)) {
> +		proc_mem_mode = PROC_MEM_ALWAYS;
> +		return;
> +	}
> +
> +	if (TST_RET == -1 && TST_ERR != EIO)
> +		tst_brk(TBROK | TTERRNO, "test write to /proc/self/mem failed");
> +
> +	/* /proc/self/mem write failed, cleanup and try ptrace mode */
> +	child_cleanup();
> +	SAFE_MUNMAP(child, sizeof(*child));
> +	child = NULL;
> +
> +	if (explicit_mode && proc_mem_mode == PROC_MEM_ALWAYS)
> +		tst_brk(TCONF,
> +			"Writes to /proc/self/mem disabled despite always mode");

The unconditional assignment `proc_mem_mode = PROC_MEM_ALWAYS`
before the probe destroys the value parsed from the kernel command
line. When the user explicitly sets proc_mem.force_override=ptrace,
this sequence occurs:

  1. Kernel cmdline parsing sets proc_mem_mode = PROC_MEM_PTRACE
     and explicit_mode = 1.
  2. Line 294 overwrites proc_mem_mode = PROC_MEM_ALWAYS.
  3. The probe write to /proc/self/mem fails (expected in ptrace
     mode).
  4. The check `explicit_mode && proc_mem_mode == PROC_MEM_ALWAYS`
     evaluates to true because the overwrite at step 2 lost the
     original choice.
  5. The test exits with TCONF "disabled despite always mode"
     instead of falling through to the ptrace path.

The user's explicit ptrace choice is silently discarded. One fix
would be to save the parsed mode in a separate variable (e.g.
`user_mode`) before the probe and test that at line 316 instead
of proc_mem_mode.

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