Re: OOM kill of privileged processes when exhausting a single NUMA node

[Michal Hocko <mhocko@suse.com>]

On Fri 27-06-25 00:21:57, Pedro Falcato wrote:
> On Thu, Jun 26, 2025 at 10:27:36PM +0000, Felix Abecassis wrote:
> > Hello linux-mm team,
> > 
> > I have found an interesting behavior in the Linux kernel: an unprivileged user
> > with access to user namespaces can cause privileged processes to be killed due
> > to an OOM situation on a single NUMA node, even if the system has plenty of
> > memory available on other NUMA nodes.
> > 
> > This might lead to a local denial of service in some situations, so please
> > review and let me know if the current behavior is expected.
> > 
> > The steps are simple:
> > 1. Use a Linux system with multiple NUMA nodes
> > 2. Enable unprivileged user namespaces (often distro dependent)
> > 3. As an unprivileged user, create a user namespace + mount namespace
> >    and mount a tmpfs bound to NUMA node 1
> > 4. Attempt to fill the tmpfs with more data than it can possibly store
> > 5. The OOM killer will kill a significant amount of system daemons
> >    (UID 0).

This is really something that our OOM handling is not able to deal with
because we cannot simply remove persistent (even if boot time scoped)
data. Even if we managed to kill a task that has consumed an excessive
amount of tmpfs data then the data will be left with the current
implementation. Changing the behavior would require defining disposable
tmpfs mounts and make any userspace aware of the fact. Otherwise we are
causing active data corruption bugs.

> I somewhat agree that this is somewhat unintended tmpfs behavior, but you can
> (probably) pull this off in other ways:

Well, it is a filesystem and as such we do not allow data corruptions.
The same way we do not simply allow removing data on ENOSPC. This
filesystem just happens to be backed by memory rather than a real
storage.

> - use set_mempolicy()/mbind to bind to a NUMA node and use a big mmap() mapping
> - just use a lot of memory
> 
> and it's not limited to NUMA either.

Right there are ways to deplete memory and therefore it is generally
recommended to contain untrusted users by memory cgroups and make sure
the untrusted user cannot consume any specific resource. NUMA topology
makes that more complicated because that adds to the resource constrains
as pointed out in the below example (hard limit harder than a single
numa node while tmpfs is configured to consume the full Numa node).

My experience with unprivileged user namespaces is limited but I would
say that you need some policy built on top if you want to allow
arbitrary tmpfs mounts.
-- 
Michal Hocko
SUSE Labs