Re: [PATCH net v3] tun: bound the NAPI receive queue

[Antonio Quartulli <antonio@mandelbit.com>]

Hi,

On 01/11/2026 03:08, Willem de Bruijn wrote:
> Antonio Quartulli wrote:
>> 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. The socket send buffer cannot bound this: tun sets it to
>> INT_MAX, and the build_skb() and XDP batch paths do not check it.
>>
>> Drop packets once more than netdev_max_backlog of them are queued, like
>> enqueue_to_backlog() does, and count them as rx_dropped: before
>> allocating and copying them where possible, and again under the queue
>> lock before queueing. This covers write(), sendmsg() and the batches of
>> XDP buffers vhost-net passes to tun_sendmsg(), which share the queue.
>> Zerocopy buffers of packets dropped early are completed.
>>
>> Reproducer, as an unprivileged user in a new user and network
>> namespace, without kernel modifications or fault injection:
>>    ip tuntap add t0 mode tun; ip addr add 10.11.0.1/24 dev t0
>>    ip link add d0 type dummy; ip addr add 10.20.0.1/24 dev d0
>>    ip link set t0 up; ip link set d0 up; sysctl net.ipv4.ip_forward=1
>>    install ~500 iptables FORWARD rules and a MASQUERADE rule on d0
>>    open t0 with IFF_TUN | IFF_NO_PI | IFF_NAPI
>>    echo 1 > /sys/class/net/t0/threaded
>>    write() 1400-byte IPv4 packets for 10.20.0.2 in a loop
>>
>> Tested with the reproducer in an x86-64 VM: memory use stays flat
>> and the forwarding rate is unchanged. The vhost-net paths are only
>> build-tested, and the kselftests have not been run yet.
> 
> Let's make sure the tun selftests pass.

I went through the tun selftest and it passed.

However, there was no coverage for vhost-net, so I took care of that 
with an extra patch (it was actually useful because I caught a hitch in 
the actual fix).

>   
>> Still open: the limit counts packets rather than bytes and applies per
>> queue, the NAPI poll splices the queue out while it runs so up to about
>> twice the limit can be in flight, 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>
>> ---
>> v3:
>> - Also bound the sendmsg() paths, which share the queue: zerocopy
>>    buffers are completed when dropped early, and the batched XDP buffers
>>    of tun_xdp_one() are covered too (Willem)
>> - Drop the IFF_NAPI_FRAGS exclusion: tun_get_user() never queues in
>>    that mode (napi_gro_frags() is synchronous), so the early check only
>>    fires if tun_xdp_one() filled the same queue, and dropping is fine
>>    then too (Willem)
>> - Recheck under the queue lock before queueing (Willem)
>> - Compare with > like enqueue_to_backlog() (Willem)
>> - Keep the includes sorted (Willem)
>> - Add the reproducer and a testing statement to the commit message
>>
>> v2: https://lore.kernel.org/netdev/20261030152540.1409884-1-antonio@mandelbit.com/
>> - Cc netdev and the 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.
>> - Mitigation: disallow unprivileged user namespaces or restrict
>>    access to /dev/net/tun.
>>
>>   drivers/net/tun.c | 39 +++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 39 insertions(+)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index 770b8fe085c3..df5f0cbd1b16 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -58,6 +58,7 @@
>>   #include <linux/nsproxy.h>
>>   #include <linux/virtio_net.h>
>>   #include <linux/rcupdate.h>
>> +#include <net/hotdata.h>
>>   #include <net/net_namespace.h>
>>   #include <net/netns/generic.h>
>>   #include <net/rtnetlink.h>
>> @@ -227,6 +228,15 @@ struct veth {
>>   static void tun_flow_init(struct tun_struct *tun);
>>   static void tun_flow_uninit(struct tun_struct *tun);
>>   
>> +/* In IFF_NAPI mode written packets wait in the tfile's sk_write_queue for the
>> + * NAPI poll, which may run later in a kthread or ksoftirqd. Bound that queue
>> + * like the per-CPU backlog of netif_rx().
>> + */
>> +static bool tun_napi_queue_full(const struct sk_buff_head *queue)
>> +{
>> +	return skb_queue_len_lockless(queue) > READ_ONCE(net_hotdata.max_backlog);
>> +}
>> +
>>   static int tun_napi_receive(struct napi_struct *napi, int budget)
>>   {
>>   	struct tun_file *tfile = container_of(napi, struct tun_file, napi);
>> @@ -1856,6 +1866,20 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
>>   			zerocopy = true;
>>   	}
>>   
>> +	/* Drop before allocating and copying when the NAPI queue is full. The
>> +	 * check is repeated under the queue lock before queueing.
>> +	 */
>> +	if (tfile->napi_enabled &&
>> +	    unlikely(tun_napi_queue_full(&tfile->sk.sk_write_queue))) {
>> +		if (msg_control) {
>> +			struct ubuf_info *uarg = msg_control;
>> +
>> +			uarg->ops->complete(NULL, uarg, false);
>> +		}
>> +		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
>> @@ -2045,6 +2069,14 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
>>   			goto free_skb;
>>   		}
>>   
>> +		if (unlikely(tun_napi_queue_full(queue))) {
>> +			spin_unlock_bh(&queue->lock);
>> +			rcu_read_unlock();
>> +			kfree_skb_reason(skb, SKB_DROP_REASON_FULL_RING);
>> +			dev_core_stats_rx_dropped_inc(tun->dev);
>> +			return total_len;
> 
> consider goto free_skb instead of open coding.

ACK.

Regards,

>> +		}
>> +
>>   		__skb_queue_tail(queue, skb);
>>   		queue_len = skb_queue_len(queue);
>>   		spin_unlock(&queue->lock);
>> @@ -2649,6 +2681,13 @@ static int tun_xdp_one(struct tun_struct *tun,
>>   			return -EBUSY;
>>   		}
>>   
>> +		if (unlikely(tun_napi_queue_full(queue))) {
>> +			spin_unlock(&queue->lock);
>> +			kfree_skb_reason(skb, SKB_DROP_REASON_FULL_RING);
>> +			dev_core_stats_rx_dropped_inc(tun->dev);
>> +			return 0;
>> +		}
>> +
>>   		__skb_queue_tail(queue, skb);
>>   		spin_unlock(&queue->lock);
>>   		ret = 1;
>> -- 
>> 2.56.0
>>
> 

-- 
Antonio Quartulli

CEO and Co-Founder
Mandelbit Srl
https://www.mandelbit.com