linux-kernel - [PATCH 0/3] netfilter/x_tables: go back to using vmalloc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250922194819.182809-1-d-tatianin@yandex-team.ru>
Date: Mon, 22 Sep 2025 22:48:16 +0300
From: Daniil Tatianin <d-tatianin@...dex-team.ru>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: Daniil Tatianin <d-tatianin@...dex-team.ru>,
	Jozsef Kadlecsik <kadlec@...filter.org>,
	Florian Westphal <fw@...len.de>,
	Phil Sutter <phil@....cc>,
	"David S. Miller" <davem@...emloft.net>,
	David Ahern <dsahern@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>,
	netfilter-devel@...r.kernel.org,
	coreteam@...filter.org,
	linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: [PATCH 0/3] netfilter/x_tables: go back to using vmalloc

This series aims to replace most calls to kvmalloc whose size directly depends
on user input with vmalloc. This was actually the way xt_table_info was
previously allocated if it ended up being too large back in 2017 before it got
replaced with a call to kvmalloc in the
commit eacd86ca3b036 ("net/netfilter/x_tables.c: use kvmalloc() in xt_alloc_table_info()").

The commit that changed it did so because "xt_alloc_table_info()
basically opencodes kvmalloc()", which is not actually what it was
doing. kvmalloc() does not attempt to go directly to vmalloc if the
order the caller is trying to allocate is "expensive", instead it only
uses vmalloc as a fallback in case the buddy allocator is not able to
fullfill the request.

The difference between the two is actually huge in case the system is
under memory pressure and has no free pages of a large order. Before the
change to kvmalloc we wouldn't even try going to the buddy allocator for
large orders, but now we would force it to try to find a page of the
required order by waking up kswapd/kcompactd and dropping reclaimable memory
for no reason at all to satisfy our huge order allocation that could easily
exist within vmalloc'ed memory instead.

Revert the change to always call vmalloc, since this code doesn't really
benefit from contiguous physical memory, and the size it allocates is
directly dictated by the userspace-passed table buffer thus allowing it to
torture the buddy allocator by carefully crafting a huge table that fits
right at the maximum available memory order on the system.

This series also touches the allocation of entry_offsets, since they suffer
from the same issue.

Daniil Tatianin (3):
  netfilter/x_tables: go back to using vmalloc for xt_table_info
  netfilter/x_tables: introduce a helper for freeing entry offsets
  netfilter/x_tables: allocate entry_offsets with vcalloc

 include/linux/netfilter/x_tables.h |  1 +
 net/ipv4/netfilter/arp_tables.c    |  4 ++--
 net/ipv4/netfilter/ip_tables.c     |  4 ++--
 net/ipv6/netfilter/ip6_tables.c    |  4 ++--
 net/netfilter/x_tables.c           | 12 +++++++++---
 5 files changed, 16 insertions(+), 9 deletions(-)

-- 
2.34.1