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

Message-ID: <558F933A-390E-408F-9D19-D1524B822778@nutanix.com>
Date: Tue, 2 Dec 2025 21:36:38 +0000
From: Jon Kohler <jon@...anix.com>
To: 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



> On Dec 2, 2025, at 4:34 PM, Willem de Bruijn <willemdebruijn.kernel@...il.com> wrote:
> 
> !-------------------------------------------------------------------|
>  CAUTION: External Email
> 
> |-------------------------------------------------------------------!
> 
> 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.

Yea thats a fair nuance. I’ll chew on it for the next go-around

Jon