linux-kernel - Re: [PATCH net-next v2 3/9] tun: correct drop statistics in tun_put

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <willemdebruijn.kernel.42db6f47db6d@gmail.com>
Date: Tue, 02 Dec 2025 16:34:13 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Jon Kohler <jon@...anix.com>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, 
 Jason Wang <jasowang@...hat.com>, 
 Andrew Lunn <andrew+netdev@...n.ch>, 
 "David S. Miller" <davem@...emloft.net>, 
 Eric Dumazet <edumazet@...gle.com>, 
 Jakub Kicinski <kuba@...nel.org>, 
 Paolo Abeni <pabeni@...hat.com>, 
 open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next v2 3/9] tun: correct drop statistics in
 tun_put_user

Jon Kohler wrote:
> 
> 
> > On Nov 28, 2025, at 10:07 PM, Willem de Bruijn <willemdebruijn.kernel@...il.com> wrote:
> > 
> > Jon Kohler wrote:
> >> Fold kfree_skb and consume_skb for tun_put_user into tun_put_user and
> >> rework kfree_skb to take a drop reason. Add drop reason to all drop
> >> sites and ensure that all failing paths properly increment drop
> >> counter.
> >> 
> >> Signed-off-by: Jon Kohler <jon@...anix.com>
> >> ---
> >> drivers/net/tun.c | 51 +++++++++++++++++++++++++++++++----------------
> >> 1 file changed, 34 insertions(+), 17 deletions(-)
> >> 
> >> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> >> index 68ad46ab04a4..e0f5e1fe4bd0 100644
> >> --- a/drivers/net/tun.c
> >> +++ b/drivers/net/tun.c
> >> @@ -2035,6 +2035,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
> >>     struct sk_buff *skb,
> >>     struct iov_iter *iter)
> >> {
> >> + enum skb_drop_reason drop_reason = SKB_DROP_REASON_NOT_SPECIFIED;
> >> struct tun_pi pi = { 0, skb->protocol };
> >> ssize_t total;
> >> int vlan_offset = 0;
> >> @@ -2051,8 +2052,11 @@ static ssize_t tun_put_user(struct tun_struct *tun,
> >> total = skb->len + vlan_hlen + vnet_hdr_sz;
> >> 
> >> if (!(tun->flags & IFF_NO_PI)) {
> >> - if (iov_iter_count(iter) < sizeof(pi))
> >> - return -EINVAL;
> >> + if (iov_iter_count(iter) < sizeof(pi)) {
> >> + ret = -EINVAL;
> >> + drop_reason = SKB_DROP_REASON_PKT_TOO_SMALL;
> > 
> > PI counts as SKB_DROP_REASON_DEV_HDR?
> 
> Are you saying I should change this use case to DEV_HDR?
> 
> This one seemed like a pretty straight forward “It’s too small” case,
> no? Or am I misreading into what you’re saying here?
> 
> Happy to take a suggestion if I’ve got the drop reason wired
> wrong (or if we need to cook up a brand new drop reason for any of
> these)

I agree that it's a clear case of the buffer being too small. But I
consider PI not part of the packet itself, but bad device headers.
It's borderline nitpicking. With that context, pick which you see fits
best.