Hi Eduard, Yiyang, Thanks for the pointer. I independently tested Yiyang's v3 series on the source-matched f105f3631d51 base with the same kernel config used for my original report.
Before the series, my impact witness reached chosen-address kernel read/write and changed UID/GID 65534 with CAP_BPF and CAP_PERFMON to UID/GID 0 in 3/3 runs. With all three v3 patches applied, the intended untrusted-pointer positive control still passed, while the impact program was rejected at "R0 pointer += pointer prohibited" before any address leak or privilege transition in 3/3 runs. I also ran the three focused cases added by the v3 series. All passed: mem_rdonly_untrusted/ldx_is_ok_commuted_addr dynptr/dynptr_slice_commuted_invalidate verifier_basic_stack/stack pointer arithmetic preserves frame number Given that the affected code has shipped and the issue reaches kernel read/write from a CAP_BPF and CAP_PERFMON context, should this be routed through bpf and marked for stable rather than bpf-next? For the v3 series: Tested-by: Daniel Wade <[email protected]> Regards, Daniel
