Re: [RFC v1 05/19] ptwrite uprobes: Add minimal low level support for x86

[Lorenzo Stoakes (ARM)]

NAK.

This is broken as described in [0] and causes use-after-frees.

[0]:https://lore.kernel.org/all/aphJ7olxr-_VhDKt@gremlin/

On Mon, Aug 31, 2026 at 08:04:41AM -0700, Andi Kleen wrote:
> Add more data structures and the x86 machinery to generate the PTWRITE
> instructions for a ptwrite uprobe. The probe executes PTWRITEs and then
> jumps back to the original code. In this variant only patching
> 5 byte nops is supported.
>
> The instructions are pre-generated to templates and then patched when
> setting up the final user page.
>
> The patching code uses 3 phase patching similar to int3_update.
>
> The ptwrite stub emits a header with a magic value and the number of
> arguments, and then the actual probed values.
>
> There is no separate config option for ptwrite uprobes, it is just tied
> to the main uprobes config.
>
> Some limitations in the current implementation:
> - The probed 5 byte area cannot cross a page.
> - The allocated stubs in the user program are only freed on exit.
>
> Assisted-by: omp:gpt-5.6-luna

I suggest looking into a model more suited to complex kernel
development. Googling it, Luna is described thusly:

'GPT-5.6 Luna is OpenAI's fastest and most budget-friendly AI model tier,
built specifically for high-volume, latency-sensitive tasks'

Which doesn't strike me as ideal for this kind of work, especially when you
are submitting things to the mailing list and asking people to dedicate
their own time (and better models) to assessing it.

> Signed-off-by: Andi Kleen <ak@xxxxxxxxxx>
> ---
>  arch/x86/include/asm/uprobes.h |  24 ++
>  arch/x86/kernel/uprobes.c      | 623 +++++++++++++++++++++++++++++++++
>  2 files changed, 647 insertions(+)

(That's a huge diffstat for one patch and your cover letter is missing a
full diffstat also...)

> diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
> index 65a2de82ecd2..df652c56414b 100644
> --- a/arch/x86/kernel/uprobes.c
> +++ b/arch/x86/kernel/uprobes.c
> @@ -15,11 +15,15 @@
>  #include <linux/syscalls.h>

...

> +static struct uprobe_ptwrite_page *
> +create_uprobe_ptwrite_page(struct mm_struct *mm, unsigned long vaddr)
> +{
> +	struct uprobe_ptwrite_page *ptw;
> +	struct vm_area_struct *vma;
> +	unsigned long area;
> +
> +	area = find_ptwrite_page_area(mm, vaddr);
> +	if (IS_ERR_VALUE(area))
> +		return NULL;
> +
> +	mmap_assert_write_locked(mm);
> +
> +	ptw = kzalloc_obj(*ptw);
> +	if (!ptw)
> +		return NULL;
> +
> +	ptw->page = alloc_page(GFP_HIGHUSER | __GFP_ZERO);
> +	if (!ptw->page) {
> +		kfree(ptw);
> +		return NULL;
> +	}
> +	ptw->vaddr = area;
> +
> +	vma = _install_special_mapping(mm, area, PAGE_SIZE,
> +			VM_READ|VM_EXEC|VM_MAYEXEC|VM_MAYREAD|VM_IO,
> +			&ptwrite_mapping);

You need to trampoline this (as the existing code does...) to avoid the
issue described in [0].

--
Cheers, Lorenzo