From: Hangbin Liu <hangbin.liu@linux.dev>
To: Hui Peng <benquike@gmail.com>
Cc: Kuniyuki Iwashima <kuniyu@google.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Willem de Bruijn <willemb@google.com>,
Tom Herbert <therbert@google.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH net v2] fou: reject omitted FOU_ATTR_IPPROTO on FOU_ENCAP_DIRECT
Date: Mon, 21 Sep 2026 14:30:17 +0800 [thread overview]
Message-ID: <arDOTqytCxWKOyxv@fedora> (raw)
In-Reply-To: <20260921045920.1613098-1-benquike@gmail.com>
On Mon, Sep 21, 2026 at 04:59:20AM +0000, Hui Peng wrote:
> Commit 7a9bc9e3f423 ("fou: Don't allow 0 for FOU_ATTR_IPPROTO.") added
> NLA_POLICY_MIN(NLA_U8, 1) to fou_nl_policy[FOU_ATTR_IPPROTO], which
> rejects an explicitly supplied FOU_ATTR_IPPROTO == 0 attribute with
> -ERANGE.
>
> However, FOU_ATTR_IPPROTO is an optional netlink attribute. When a user
> sends FOU_CMD_ADD with FOU_ATTR_TYPE set to FOU_ENCAP_DIRECT and omits
> FOU_ATTR_IPPROTO entirely, nla_policy validation succeeds and
> parse_nl_config() leaves cfg->protocol as 0 (from memset(cfg, 0,
> sizeof(*cfg))). fou_create() then creates a FOU_ENCAP_DIRECT socket with
> fou->protocol == 0.
>
> In fou_udp_recv(), returning -fou->protocol to udp_queue_rcv_one_skb()
> triggers IP protocol resubmission when fou->protocol > 0, whereas
> returning 0 tells the UDP tunnel layer that the skb was consumed without
> freeing it. When fou->protocol == 0, every packet received on the socket
> returns 0 from fou_udp_recv() and leaks the sk_buff.
>
> Reject FOU_ENCAP_DIRECT when !cfg->protocol in fou_create() so that
> creating a direct encapsulation port without FOU_ATTR_IPPROTO fails with
> -EINVAL while leaving FOU_CMD_DEL and FOU_CMD_GET (which share
> parse_nl_config()) unaffected.
>
> Tested in QEMU against Linux 7.3.0-rc3 by sending a FOU_CMD_ADD Generic
> Netlink request with FOU_ATTR_PORT = 5555 and FOU_ATTR_TYPE =
> FOU_ENCAP_DIRECT while omitting FOU_ATTR_IPPROTO. On the unfixed kernel,
> FOU_CMD_ADD succeeds (err = 0), FOU_CMD_GET reports fou->type = 1 and
> fou->protocol = 0, and sending 4000 UDP packets to 127.0.0.1:5555 leaks
> all 4000 sk_buffs (SUnreclaim in /proc/meminfo grows from 41456 kB to
> 59008 kB, +17552 kB); with this patch applied, FOU_CMD_ADD is rejected
> with -EINVAL (-22).
>
> Fixes: 23461551c006 ("fou: Support for foo-over-udp RX path")
> Fixes: 7a9bc9e3f423 ("fou: Don't allow 0 for FOU_ATTR_IPPROTO.")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Hui Peng <benquike@gmail.com>
> ---
> Changes in v2:
> - Clarify in the commit message that fou->protocol == 0 is reached on
> current kernels by omitting the optional FOU_ATTR_IPPROTO attribute
> when FOU_ATTR_TYPE is FOU_ENCAP_DIRECT (whereas an explicit 0
> attribute is rejected by commit 7a9bc9e3f423), as noted by Kuniyuki
> Iwashima and Sashiko.
> - Move the !cfg->protocol check from parse_nl_config() into the
> FOU_ENCAP_DIRECT branch of fou_create() so FOU_CMD_DEL and FOU_CMD_GET
> are not affected, and drop the redundant check in fou_udp_recv(), as
> suggested by Sashiko.
> - Fix the Fixes: commit tags to 23461551c006 and 7a9bc9e3f423, as
> pointed out by Hangbin Liu and Kuniyuki Iwashima.
>
> net/ipv4/fou_core.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/ipv4/fou_core.c b/net/ipv4/fou_core.c
> index 5e867f1b5c1d..f30f22389283 100644
> --- a/net/ipv4/fou_core.c
> +++ b/net/ipv4/fou_core.c
> @@ -600,6 +600,10 @@ static int fou_create(struct net *net, struct fou_cfg *cfg,
> /* Initial for fou type */
> switch (cfg->type) {
> case FOU_ENCAP_DIRECT:
> + if (!cfg->protocol) {
> + err = -EINVAL;
> + goto error;
> + }
> tunnel_cfg.encap_rcv = fou_udp_recv;
> tunnel_cfg.gro_receive = fou_gro_receive;
> tunnel_cfg.gro_complete = fou_gro_complete;
> --
> 2.49.0
Looks good to me.
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
next prev parent reply other threads:[~2026-09-21 6:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-19 21:52 [PATCH] fou: reject FOU_ENCAP_DIRECT with protocol 0 to prevent sk_buff leak Hui Peng
2026-09-20 7:12 ` Hangbin Liu
2026-09-20 19:19 ` Kuniyuki Iwashima
2026-09-21 4:59 ` [PATCH net v2] fou: reject omitted FOU_ATTR_IPPROTO on FOU_ENCAP_DIRECT Hui Peng
2026-09-21 6:30 ` Hangbin Liu [this message]
2026-09-24 2:10 ` patchwork-bot+netdevbpf
2026-09-20 21:55 ` [PATCH] fou: reject FOU_ENCAP_DIRECT with protocol 0 to prevent sk_buff leak netdev-bot+sashiko
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=arDOTqytCxWKOyxv@fedora \
--to=hangbin.liu@linux.dev \
--cc=benquike@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=therbert@google.com \
--cc=willemb@google.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.