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

[Jiayuan Chen]

On Wed, May 20, 2026 at 09:59:14AM +0800, John Fastabend wrote:
> On Wed, May 20, 2026 at 11:09:36AM +0000, bot+bpf-ci@xxxxxxxxxx wrote:
> > > diff --git a/net/core/filter.c b/net/core/filter.c
> > > index 9590877b0714..223d78708486 100644
> > > --- a/net/core/filter.c
[...]
> > 
> > Could the ring buffer state become corrupted when data is appended exactly
> > at the end of the message and the ring buffer is full?
> > 
> > If data is appended exactly at the end of the message (start == offset +
> > l), the loop finishes with i pointing to the unused slot msg->sg.end. If
> > the ring buffer is full (!space), the coalescing fallback logic reads:
> > 
> >    copy = msg->sg.data[i].length
> > 
> > Because i points to an unused slot, its length is 0, making copy == 0, and
> > the fallback coalescing block is bypassed. The function then
> > unconditionally calls:
> > 
> >    sk_msg_iter_next(msg, end)
> > 
> > which increments msg->sg.end. Since the ring buffer was already full,
> > advancing msg->sg.end causes it to wrap around and equal msg->sg.start.
> > This could corrupt the ring buffer state and overwrite the first element
> > without calling put_page(), leading to page leaks.
> 
> ^^^
> 
> This one I haven't looked into yet. Let me know if you have time to get
> to above two issues this week would be great to get a v1 out at least.
> 
> Thanks,
> John

Hi John,

Those issues have been reported by Weiming and corresponding patchs look good to me.

https://lore.kernel.org/bpf/11e4c78b-dd7b-44f7-800f-cf64517f4a1d@xxxxxxxxx/
https://lore.kernel.org/bpf/1f2485da-257f-4654-a2cd-8108228ece46@xxxxxxxxx/
https://lore.kernel.org/bpf/daab27eb-2763-462b-8a9f-34adf0c92e0b@xxxxxxxxx/

But unfortunately those patchs has been archived automatically. I think I can
just resend those patchs with Weiming's credit (author), and with your review
tags, those patchs can be merged sucessfully.