Re: thp04: Fix PTRACE mode for CONFIG_PROC_MEM_FORCE_PTRACE=y

On Fri, Jun 12, 2026 at 07:21:42PM +0000, [email protected] wrote:
> 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
Hi,

thanks for the review.
Both issues have already been addressed in v3. I'll send the updated
version shortly.

Thanks,
Jan

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