Re: [SECURITY] BPF task_work context confusion enables cross-process bpf_probe_write_user() via token delegation

[Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>]

Hi,
Ask your LLM why this is not a security issue. 
Mine did well providing the right answer.

It would be a good idea to do a little bit more due diligence 
before reporting issues like this.

On 5/3/26 3:28 PM, Keshav goyal wrote:
> Hello Linux Kernel Security Team,
> I would like to report a potential security issue in the BPF subsystem involving task_work scheduling and context confusion.
> 
> Summary
> -------
> A BPF tracing program can target an arbitrary PID using bpf_task_from_pid() and schedule a callback via bpf_task_work_schedule_signal(). The callback executes in the context of the target task, allowing bpf_probe_write_user() to write into that task’s userspace memory.
> 
> This effectively turns the helper from “write current task memory” into “write arbitrary target process memory”.
> 
> Impact
> ------
> This creates a cross-process userspace memory write primitive.
> 
> I have confirmed that:
> - The target process can be root-owned
> - No ptrace or same-UID checks are required
> - The write occurs successfully in the victim process memory
> 
> Importantly, I was able to reproduce this not only as root, but also via a token-delegated BPF loader in a user namespace (using libbpf BPF token support).
> 
> This suggests a potential privilege-boundary bypass depending on deployment of delegated BPF capabilities.
> 
> Proof of Concept
> ----------------
> I am attaching:
> - PoC source code
> - build + run instructions
> - screenshots demonstrating memory modification
> - logs showing successful execution
> 
> Key observed output:
> 
>   scheduled=... ran=... err=0
>   BUF=AAAAAAAAAAAAAAAA
>   BUF=BPFOKAAAAAAAAAAA
> 
> This confirms that a BPF program modified memory of another process.
> 
> Root Cause
> ----------
> The issue appears to arise from the following behavior:
> 
> - bpf_task_from_pid() resolves arbitrary tasks
> - bpf_task_work_schedule_signal() queues attacker-controlled work
> - task_work executes in the target task context (current == victim)
> - bpf_probe_write_user() writes to current->mm without validating origin
> 
> This combination allows cross-process memory writes.
> 
> Environment
> -----------
> - Kernel: upstream built from kernel.org <http://kernel.org/> (latest mainline at time of testing)
> - Architecture: x86_64
> - Test setup: QEMU VM with custom kernel
> - BPF features: BTF enabled, tracing programs allowed, lockdown disabled
> 
> Reproduction
> ------------
> I have included step-by-step reproduction instructions in the attached materials. The issue is reliably reproducible.
> 
>  I was able to reproduce the same behavior using a token-delegated BPF loader running inside a user namespace (via LIBBPF_BPF_TOKEN_PATH), rather than directly as init-namespace root.
> 
> In this setup:
> - The loader runs as a non-root user (UID 1000 mapped inside a user namespace)
> - BPF access is granted via a token
> - The target process is still a root-owned process in the init namespace
> 
> Even in this configuration, the BPF program successfully schedules task_work on the target and bpf_probe_write_user() modifies the victim’s userspace memory.
> 
> Example output:
> 
>   scheduled=... ran=... err=0 
>   BUF=AAAAAAAAAAAAAAAA 
>   BUF=BPFOKAAAAAAAAAAA 
> 
> This suggests the behavior is not limited to fully privileged root contexts, but also applies in delegated BPF scenarios.
> 
> Request
> -------
> I would appreciate your guidance on:
> - whether this is considered a valid security boundary violation
> - recommended disclosure process
> - whether additional hardening or checks are expected here
> 
> Please let me know if any additional information or testing is required.
> 
> Thank you for your time and for maintaining the kernel.
> 
> Best regards,  
> Keshav Goyal
> 
> IMG1:
> IMG 1.png
> 
> IMG2:
> IMG 2.png
> IMG3:
> IMG 3.png
> IMG4:
> IMG 4.png
> IMG5.1:
> IMG 5.1.png
> IMG5.2:
> IMG 5.2.png
> 
> 
>