From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 994B43438AD for ; Thu, 21 May 2026 00:05:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779321919; cv=none; b=N5ZgSW4TVTqSyXLuPx1gyWTV4jmFHOITzViEuR1pZWcPKU3cKQ36DRkcj+w3bI0KOwe7th7Jl4bbVB3d6+XPrhJ9AB7hmfQWVDXMeChqTcQwxJEp7CKAbDajJ7WzseOeDmhG62juXMimXggK/wJv3Sj0hWqwWSJv1fLWlOj0NoA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779321919; c=relaxed/simple; bh=BbtGjjmeI2nVsSBJfqYLmKm3sQ2wmIxqjbeHSi9rv+A=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=SxQIdOaH5WsmXZ8i8EelcOiFosX4PnoAFYiOtU/kUFSPvoWeFlLAZAM9Yk4eLLFb91fBTyImoXohqDuoqZ0u/ea9UrIYaBLggDTnmj+g8IPC1yU2BafTKPF8mZuMuHimNdLPZeizKeT7uRkTbiV8CYe7T6pp74V8Pb0An2NxS4g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=qgjvGo5D; arc=none smtp.client-ip=209.85.128.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qgjvGo5D" Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-7bf1eaba464so50536677b3.1 for ; Wed, 20 May 2026 17:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779321918; x=1779926718; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=W4bH0PWwVzIcDIt4+BnyuzrmluUQcP68Q7Zx7vTal4I=; b=qgjvGo5DQZcfdXg2G8z4VJQW8GFXwVJm1jmYgoM0uHpewOTkVKDK4rbTjNEG8NdS2d QZ5dFje1OVRpTXJcplj9g81EomQrO3H2AsPnNOEJXmTzCFF5+cDgWKUTTMMlO5H407BT mfo/Rq/YZlBTizeafQweDV0ZHa+6jeYdo6MumZ7epnerdXsKGKZ0HVPtJ/vAYZkAK11n Z/tFxOhM5bQJsmknUNBBl7KlkuflVMHWsvz8dzeRa8BPUbiMKNE7ykDJH3tJWA/YpzpG KAZw2GXQ2irOJuWJi/htqSmTjfTujYWyU/DmawAaYHPQvasfIN+Y8wuTOE+LkjQUsSl5 BgfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779321918; x=1779926718; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=W4bH0PWwVzIcDIt4+BnyuzrmluUQcP68Q7Zx7vTal4I=; b=UL/AXBgbIKo6a6y7oq2Bzk4mAqRyvST80X5ZSzQGDvrIXv+h8HWMWy8ZfULXhrUAVi tW6QCOgLaqcei4DLoAvh2Vpnnrlp4DgcOzT8tZumXwrJhEO2eR/I+xH2lyZ5MEDVv2I2 aS2jvkyHc3A6MCH2vAmX2vzWojKoUccgcSNa0Hjg35z/dm8vr/x4iodMB5cqPcGS76iZ 4ejiCwoE2pTVRICZx25LcSTM8/SJ1P7600vm4wK/JxTnplaCYHfFHmShBg4R8Qg5GyGS d+2cldAxLKuecGMGCoefFNECf4GTDarHMmTXPUtnmBiI5zvlLEMRBQARsy6+9aRW7A3U RhkA== X-Forwarded-Encrypted: i=1; AFNElJ/Iwxrfc5NW6x2JhnTR+Qo0UbvNH1Fbv+7yqYJT3KBuGgAUF1l2KCakoc2ElNi6SJmwbryHu44FaekVxEQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxlRVPkoJvm9i/1E247pLsWzF8C/8yTv8lbMac4UhaVAsohAQ3/ CR3o1igeRIJuxxGXjvPuQ+DqKU30abtQ9FLKaMU/im2pM0IOC+u5GGRO X-Gm-Gg: Acq92OG4e/nMGZnY2Hn6ehCZLnvdIQaie6SZfTQshr41SqwYwFvCJ0BBEx4ttBSQJVR bO+AA00voQnI2/yVOFAOioHNuEk2fRQqiSXnV4qzFwlukrYJ3b6uYPimys3/AaAtt86ZrtoxRkv UNPHXtvjsFWt/uwUgj2yG2mwaiMyIaBjm8mpkitQmFokxfS3F4hw2lbIVrIqLx5Vx5lcJzDztn3 WhLRXN9BFsx9nioPioFn6QmaqYrGsBMULl/31qMu9BkUlgxyan8+2OvsR//H00hLF2VKzoWHAA4 Cr92B+lss5rrX9sjSTdmfKa8waiYlDlLBdQlvFyE9b8hf/K18QvIGKy2XWh5zMTYZcwPC8xwRvJ 3ihwqfSqSKLEZ3e36L8idu8sUeycT5wBAz9sy8LBk+6ublmdhv/u3gY6Tsyy4xxy446dCWMo4Ns NYpiVvaEOMr8YJGiVTVMGb8TNwXq6VtPW6Yc8eO573Mp/wHst5uymWR9NWsf1VJn9KyhsoCXJrp 0e9 X-Received: by 2002:a05:690c:9b08:b0:7d0:4824:6411 with SMTP id 00721157ae682-7d20dff3867mr7208317b3.47.1779321917557; Wed, 20 May 2026 17:05:17 -0700 (PDT) Received: from gmail.com (172.235.85.34.bc.googleusercontent.com. [34.85.235.172]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7cc991c9aefsm59495767b3.9.2026.05.20.17.05.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 May 2026 17:05:17 -0700 (PDT) Date: Wed, 20 May 2026 20:05:16 -0400 From: Willem de Bruijn To: Weiming Shi , netdev@vger.kernel.org Cc: willemdebruijn.kernel@gmail.com, jasowang@redhat.com, pabeni@redhat.com, kuba@kernel.org, edumazet@google.com, dongli.zhang@oracle.com, xmei5@asu.edu, linux-kernel@vger.kernel.org, Weiming Shi Message-ID: In-Reply-To: <20260520160020.375349-2-bestswngs@gmail.com> References: <20260520160020.375349-2-bestswngs@gmail.com> Subject: Re: [PATCH net] tun: free page on short-frame rejection in tun_xdp_one() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Weiming Shi wrote: > tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without > freeing the page that vhost_net_build_xdp() allocated for it. > tun_sendmsg() discards that -EINVAL and still returns total_len, so > vhost_tx_batch() takes the success path and never frees the page; each > short frame in a batch leaks one page-frag chunk. > > A local process that can open /dev/net/tun and /dev/vhost-net can hit > this path: it attaches a tun/tap device as the vhost-net backend and > feeds TX descriptors whose length minus the virtio-net header is below > ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a > tight submission loop exhausts host memory and triggers an OOM panic. > Free the page before returning -EINVAL, matching the XDP-program error > path in the same function. > > Fixes: 049584807f1d ("tun: add missing verification for short frame") > Reported-by: Xiang Mei > Assisted-by: Claude:claude-opus-4-7 > Signed-off-by: Weiming Shi > --- > drivers/net/tun.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > index b183189f1853..f594360d66d6 100644 > --- a/drivers/net/tun.c > +++ b/drivers/net/tun.c > @@ -2394,8 +2394,10 @@ static int tun_xdp_one(struct tun_struct *tun, > bool skb_xdp = false; > struct page *page; > > - if (unlikely(datasize < ETH_HLEN)) > + if (unlikely(datasize < ETH_HLEN)) { > + put_page(virt_to_head_page(xdp->data)); > return -EINVAL; > + } Make sense, thanks. The error path from tun_xdp_act does the same. And the default: label used to too, before a batching optimization was introduced. Is the same then also missing if build_skb fails?