From: Antonio Quartulli <antonio@mandelbit.com>
To: willemdebruijn.kernel@gmail.com, jasowangio@gmail.com
Cc: Antonio Quartulli <antonio@mandelbit.com>,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@kernel.org,
kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org
Subject: [PATCH net v2] tun: bound the NAPI receive queue
Date: Fri, 30 Oct 2026 16:25:36 +0100 [thread overview]
Message-ID: <20261030152540.1409884-1-antonio@mandelbit.com> (raw)
With IFF_NAPI, tun_get_user() queues every written packet for NAPI on
an unbounded list. When the poll runs asynchronously (threaded NAPI)
and is slower than the writer, the queue grows until the system runs
out of memory. An unprivileged user can do this from its own user and
network namespaces, and the queued skbs are not charged to its memcg:
in a test VM, a uid 1000 process limited to 128 MB caused a global OOM
in ~6 seconds.
Drop packets written while netdev_max_backlog of them are queued,
before allocating them, and count them as rx_dropped. The sendmsg()
path, whose callers pass zerocopy buffers, is left alone.
Still open: the limit counts packets rather than bytes and applies per
queue, and the queued skbs are still not charged to the writer's memcg.
Found, fixed and tested with the help of an AI coding assistant
(Claude Code).
Fixes: 943170998b20 ("tun: enable NAPI for TUN/TAP driver")
Signed-off-by: Antonio Quartulli <antonio@mandelbit.com>
---
v2:
- Cc'ong netdev and maintainers
Notes:
- Affected since 943170998b20 (v4.15). Reproduced on mainline
7be4bc52fd9e; the code is unchanged in net/main 94cea342e891, which
this patch is based on and was build-tested (W=1) against. The
before/after runtime tests were done on 7be4bc52fd9e.
- Conditions: unprivileged user namespaces allowed, /dev/net/tun
accessible (0666 with the usual udev rule), threaded NAPI.
- Mitigation: disallow unprivileged user namespaces or restrict
access to /dev/net/tun.
- A reproducer is available on request.
drivers/net/tun.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 770b8fe085c3..1ace0c1f22f2 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -60,6 +60,7 @@
#include <linux/rcupdate.h>
#include <net/net_namespace.h>
#include <net/netns/generic.h>
+#include <net/hotdata.h>
#include <net/rtnetlink.h>
#include <net/sock.h>
#include <net/xdp.h>
@@ -1856,6 +1857,17 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
zerocopy = true;
}
+ /* In NAPI mode packets are queued here and processed by the NAPI
+ * poll, possibly in a kthread or ksoftirqd. Bound that queue like
+ * the per-CPU backlog, and drop before allocating and copying.
+ */
+ if (tfile->napi_enabled && !frags && !msg_control &&
+ unlikely(skb_queue_len_lockless(&tfile->sk.sk_write_queue) >=
+ READ_ONCE(net_hotdata.max_backlog))) {
+ dev_core_stats_rx_dropped_inc(tun->dev);
+ return total_len;
+ }
+
if (!frags && tun_can_build_skb(tun, tfile, len, noblock, zerocopy)) {
/* For the packet that is not easy to be processed
* (e.g gso or jumbo packet), we will do it at after
--
2.56.0
reply other threads:[~2026-10-30 15:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261030152540.1409884-1-antonio@mandelbit.com \
--to=antonio@mandelbit.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=jasowangio@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox