Re: [PATCH net v2 0/1] xsk: fix unaccounted ring allocations causing memory exhaustion

On Fri, Jul 31, 2026 at 7:19 AM Stanislav Fomichev <[email protected]> wrote:
>
> On 07/30, Zihan Xi wrote:
> > Hi Linux kernel maintainers,
> >
> > We found and validated a issue in net/xdp/xsk_queue.c. The bug is reachable by a
> > non-root user via user and net namespace.
> > We've tested it, and it should not affect any other functionality.
> >
> > We will provide detailed information about the bug
> > in this email, along with a PoC to trigger it.
> >
> > ---- details below ----
> >
> > Bug details:
> >
> > AF_XDP lets user space allocate RX, TX, UMEM fill and UMEM completion
> > rings with setsockopt() and mmap them into the process. The shared
> > xskq_create() helper allocates the ring backing memory, but unlike UMEM
> > registration it does not account those pages against RLIMIT_MEMLOCK /
> > user->locked_vm.
> >
> > As a result, a process with CAP_NET_RAW in a user and network namespace
> > can request very large rings and pin a large amount of kernel memory
> > before bind or any packet I/O. In our original report the resulting OOM
> > ended in a panic because that guest had panic_on_oom enabled. The panic
> > was only the environment-specific end result; the bug itself is the
> > missing resource boundary that lets ring allocations consume excessive
> > memory in the first place.
> >
> > The first version tried to bound these allocations with sysctl_optmem_max,
> > but that was the wrong resource model. We also evaluated a memcg-accounted
> > vmalloc path as suggested,
>
> [..]
>
> > but memcg attribution by itself did not impose
> > a default enforcement boundary in our validation setup.
>
> Can you expand on this? Maybe we don't pass some GFP_ACCOUNT flag or
> something?
>
> > AF_XDP already
> > uses RLIMIT_MEMLOCK / user->locked_vm to bound pinned UMEM pages, and the
> > ring pages are likewise user-controlled, mmapable and long-lived. This
> > version therefore accounts AF_XDP ring allocations with the existing
> > mm_account_pinned_pages() helper and unaccounts them when the queue is
> > destroyed, so ring memory is constrained by the same default limit model
> > already used for AF_XDP UMEM pages.
>
> We get RLIMIT_MEMLOCK just because the users do mmap(), nothing af_xdp
> specific. Idk, manually doing accounting seems a bit wrong, memcg/kmem seems
> like the way to go. (also, panic on oom also still seems wrong)

Hi Stanislav,

Thanks, this is helpful.

For the memcg experiment, it was not a case of missing GFP_ACCOUNT.

I changed the AF_XDP ring allocation path in xskq_create() to use an
accounted VM_USERMAP vmalloc path, and the local repro logs showed that
the allocation did in fact reach __vmalloc_node_range_noprof() with
GFP_KERNEL_ACCOUNT set.

The relevant serial log lines from the memcg-accounted prototype were:

    poc invoked oom-killer:
gfp_mask=0x402dc2(GFP_KERNEL_ACCOUNT|__GFP_HIGHMEM|__GFP_ZERO|__GFP_NOWARN),
order=0, oom_score_adj=0
     __vmalloc_node_range_noprof+0x2f7/0x8e0
     ? xskq_create+0x23/0xf0
     xskq_create+0xb8/0xf0

and also:

    oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0

So what I was trying to describe was not that memcg accounting was
missing or broken. In the validation setup, the task was running without
an effective memcg limit, so adding GFP_KERNEL_ACCOUNT changed
attribution, but did not create an effective enforcement boundary there.
The ring allocation was still only constrained by global memory pressure
in that environment.

I agree with your point that panic_on_oom only affected the final
observable outcome. The panic itself was not the core issue; it just
made the memory exhaustion easier to observe.

I also understand your concern that charging these allocations to
RLIMIT_MEMLOCK / locked_vm is probably the wrong direction if the
intended ownership model for this memory is memcg/kmem rather than a
separate AF_XDP-side accounting model.

Given that, I will stop pursuing the RLIMIT_MEMLOCK approach for now
and re-evaluate whether there is a memcg-native way to address this, or
whether this is better treated as something that should be handled by
cgroup policy.

Thanks,
Zihan