Re: [PATCH v2] bpf, sockmap: keep sk_msg copy state in sync

[Jiayuan Chen <jiayuan.chen@linux.dev>]

On 5/17/26 8:16 PM, Zhang Cen wrote:
> SK_MSG uses msg->sg.copy as per-scatterlist-entry provenance. Entries
> with this bit set are copied before data/data_end are exposed to SK_MSG
> BPF programs for direct packet access.
>
> bpf_msg_pull_data(), bpf_msg_push_data() and bpf_msg_pop_data() rewrite
> the sk_msg scatterlist ring by collapsing, splitting and shifting
> entries. These operations move msg->sg.data[] entries, but the parallel
> copy bitmap can be left behind or stale in slots that no longer contain
> the original entry. A copied entry can therefore later occupy a slot whose
> copy bit is clear and be exposed as directly writable packet data.
>
> Keep msg->sg.copy synchronized with scatterlist entry moves, preserve the
> copy bit when an entry is split, clear it when a helper replaces an entry
> with a private page, and clear every slot vacated by pull-data
> compaction.
>
> Fixes: 015632bb30da ("bpf: sk_msg program helper bpf_sk_msg_pull_data")
> Fixes: 6fff607e2f14 ("bpf: sk_msg program helper bpf_msg_push_data")
> Fixes: 7246d8ed4dcc ("bpf: helper to pop data from messages")
> Cc: stable@vger.kernel.org
> Co-developed-by: Han Guidong <2045gemini@gmail.com>
> Signed-off-by: Han Guidong <2045gemini@gmail.com>
> Signed-off-by: Zhang Cen <rollkingzzc@gmail.com>
> ---
> v2:
> Sashiko-bot pointed out that bpf_msg_pull_data() could leave stale copy
> bits on collapsed tail entries.
>
> Clear msg->sg.copy for every entry consumed by bpf_msg_pull_data()
> before compacting the scatterlist ring.
>
> While researching recent page cache bugs, we discovered this bug.
> We confirmed it allows overwriting the page cache of read-only files
> via splice(). We haven't attempted to write an exploit, but the
> corruption primitive is verified. PoC available upon request.
> Recommend fixing ASAP.

I think only "splice() + KTLS + sockmap" is vulnerable, right ?

I digded a lot but didn't find any other combo.

Actually the normal TCP/UDP  with splice() will not go through sockmap 
(unsupported yet)





I think only "splice() + KTLS + sockmap" is vulnerable, right ?

I digded a lot but didn't find any other combo.