All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Asim Viladi Oglu Manizada <manizada@pm.me>,  netdev@vger.kernel.org
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	 Jason Wang <jasowangio@gmail.com>,
	 Andrew Lunn <andrew+netdev@lunn.ch>,
	 "David S . Miller" <davem@davemloft.net>,
	 Eric Dumazet <edumazet@google.com>,
	 Jakub Kicinski <kuba@kernel.org>,
	 Paolo Abeni <pabeni@redhat.com>,
	 daniel@iogearbox.net
Subject: Re: [PATCH net] tun: prevent underflow in rx headroom calculation
Date: Tue, 21 Jul 2026 03:59:55 -0400	[thread overview]
Message-ID: <willemdebruijn.kernel.1f0c43b9fce2d@gmail.com> (raw)
In-Reply-To: <20260721014117.2234892-1-manizada@pm.me>

Asim Viladi Oglu Manizada wrote:
> tun_get_user() calculates good_linear with SKB_MAX_HEAD(align). The align
> value comes from ndo_set_rx_headroom() and can be larger than the linear
> space available in a one-page skb head.
> 
> OVS can reach this case by carrying headroom from a netkit/VXLAN port to a
> TUN port. SKB_MAX_HEAD() then underflows, leaving good_linear negative.

Separate from protecting tun from such huge headroom, which is good:

Is cooking paths with such huge headroom itself incorrect? Should
netkit have some reasonable upper bound on configurable headroom?
Netkit is not the only path that can reach this, right?

> Assigning that value to the size_t linear variable in tun_get_user()
> converts it to a large positive value. The wrapped value is passed to
> tun_alloc_skb(), where prepad + linear and len - linear wrap. skb->data can
> then end up past the allocated head, and later packet processing can access
> memory outside the skb.
> 
> Clamp good_linear to zero when SKB_MAX_HEAD() returns a negative value.
> This lets tun_alloc_skb() allocate the requested headroom and place the
> packet data linearly or in fragments without wrapping.
> 
> Fixes: eaea34b23c46 ("net/tun: implement ndo_set_rx_headroom")
> Cc: stable@vger.kernel.org
> Assisted-by: avom-custom-harness:gpt-5.5-qwen3.6-mod-mix
> Signed-off-by: Asim Viladi Oglu Manizada <manizada@pm.me>

Reviewed-by: Willem de Bruijn <willemb@google.com>

      reply	other threads:[~2026-07-21  7:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-21  1:43 [PATCH net] tun: prevent underflow in rx headroom calculation Asim Viladi Oglu Manizada
2026-07-21  7:59 ` Willem de Bruijn [this message]

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=willemdebruijn.kernel.1f0c43b9fce2d@gmail.com \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jasowangio@gmail.com \
    --cc=kuba@kernel.org \
    --cc=manizada@pm.me \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.