The VNI filter interface accepts a START/END range with no bound on
either endpoint and no bound on the total a single message may ask for,
and the memory it allocates per VNI is not charged to the caller's
cgroup.

Patches 1 and 2 bound the request. The first range-validates both
endpoints against the 24-bit VNI space, which also removes a loop whose
counter is signed while the bound it is compared against is not. The
second caps the total number of VNIs one message may span at 4096,
summed across every VXLAN_VNIFILTER_ENTRY rather than per entry, since
a message may carry any number of entries. Neither bounds how many VNIs
a device may hold.

Patch 3 makes netdev_alloc_pcpu_stats() use GFP_KERNEL_ACCOUNT, as
suggested on v1; it affects 34 call sites in 25 files, all of which
already handle a NULL return. Patch 4 accounts the VNI node itself.
Patch 5 adds selftests for the new limits.

v2:
 - target net-next, drop the Fixes tags, and post as a new thread, per
   review of v1
 - split the range validation out of the cap into its own patch
 - cap the per-message total instead of the per-entry span
 - account in netdev_alloc_pcpu_stats() rather than at the call site
 - trim the changelogs

v1: https://lore.kernel.org/netdev/20260909092645.3105263-1-alishmery18@gmail.com/

Ali Firas (5):
  vxlan: vnifilter: reject VNIs outside the 24-bit space
  vxlan: vnifilter: bound the number of VNIs one request may touch
  net: account per-CPU netdev stats to memcg
  vxlan: vnifilter: account the VNI node to memcg
  selftests: net: test the vxlan vnifilter VNI limit

 drivers/net/vxlan/vxlan_vnifilter.c           | 103 ++++++++++++++++--
 include/linux/netdevice.h                     |   2 +-
 .../selftests/net/test_vxlan_vnifiltering.sh  |  34 ++++++
 3 files changed, 126 insertions(+), 13 deletions(-)

-- 
2.53.0