mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: fmancera@suse.de
Cc: netdev@vger.kernel.org, horms@kernel.org, kuba@kernel.org,
	pabeni@redhat.com, edumazet@kernel.org, davem@davemloft.net,
	johannes@sipsolutions.net, linux-wireless@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 15/16 net-next v3] netlabel: cipso: introduce CONFIG_CIPSO to decouple IPv4 dependency
Date: Sun, 04 Oct 2026 17:22:35 +0000	[thread overview]
Message-ID: <179113455547.434549.7410696405500353621@kernel.org> (raw)
In-Reply-To: <20260930135334.4739-16-fmancera@suse.de>

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] When CONFIG_CIPSO=n, the NetLabel management PROTOCOLS dump
  still tells userspace that CIPSOv4 is supported.

--

netlabel: cipso: introduce CONFIG_CIPSO to decouple IPv4 dependency

This patch adds a new CONFIG_CIPSO symbol, which is enabled when both
NETLABEL and IPV4 are set. The CIPSO Makefile targets, sysctls and kernel
APIs are placed behind it, and the CIPSO kAPI is stubbed out when it is
disabled. This lets NetLabel and Smack build on IPv6-only kernels.

[ ... ]

> diff --git a/net/netlabel/Makefile b/net/netlabel/Makefile
> index 5a46381a64e77..8afc1bf004243 100644
> --- a/net/netlabel/Makefile
> +++ b/net/netlabel/Makefile
> @@ -12,5 +12,5 @@ obj-y	+= netlabel_mgmt.o
>
>  # protocol modules
>  obj-y	+= netlabel_unlabeled.o
> -obj-y	+= netlabel_cipso_v4.o
> +obj-$(CONFIG_CIPSO) += netlabel_cipso_v4.o
>  obj-$(subst m,y,$(CONFIG_IPV6)) += netlabel_calipso.o
> diff --git a/net/netlabel/netlabel_cipso_v4.h b/net/netlabel/netlabel_cipso_v4.h
> index 9518ab56ec98f..fb718f86bcbd7 100644
> --- a/net/netlabel/netlabel_cipso_v4.h
> +++ b/net/netlabel/netlabel_cipso_v4.h
> @@ -147,6 +147,13 @@ enum {
>  #define NLBL_CIPSOV4_A_MAX (__NLBL_CIPSOV4_A_MAX - 1)
>
>  /* NetLabel protocol functions */
> +#if IS_ENABLED(CONFIG_CIPSO)
>  int netlbl_cipsov4_genl_init(void);
> +#else
> +static inline int netlbl_cipsov4_genl_init(void)
> +{
> +	return 0;
> +}
> +#endif

[Severity: Medium]
With CONFIG_CIPSO=n, does the NLBL_MGMT_C_PROTOCOLS dump still tell
userspace that CIPSOv4 is supported?

This stub means the "NLBL_CIPSOv4" generic netlink family is never
registered. The rest of the CIPSO kAPI is stubbed out too, for example
cipso_v4_doi_getdef() returns NULL. But netlbl_mgmt_protocols() in
net/netlabel/netlabel_mgmt.c still reports CIPSOv4 unconditionally:

net/netlabel/netlabel_mgmt.c:netlbl_mgmt_protocols() {
    ...
	if (protos_sent == 1) {
		if (netlbl_mgmt_protocols_cb(skb,
					     cb,
					     NETLBL_NLTYPE_CIPSOV4) < 0)
			goto protocols_return;
		protos_sent++;
	}
#if IS_ENABLED(CONFIG_IPV6)
	if (protos_sent == 2) {
		if (netlbl_mgmt_protocols_cb(skb,
					     cb,
					     NETLBL_NLTYPE_CALIPSO) < 0)
			goto protocols_return;
		protos_sent++;
	}
#endif
    ...
}

The CALIPSO entry is guarded by CONFIG_IPV6, but the CIPSOv4 entry has no
guard.

On an IPv6-only kernel with NetLabel enabled (for example selected by
SMACK), userspace such as netlabel_tools would see CIPSOv4 in the list.
It would then fail to resolve the CIPSOv4 genl family. An NLBL_MGMT_C_ADD
with NLBL_MGMT_A_CV4DOI would also fail, because cipso_v4_doi_getdef()
returns NULL.

At this commit IPV4 is still def_bool y, so CIPSO always matches NETLABEL.
The later commit in the series, "ipv4: make CONFIG_IPV4 boolean", makes
IPV6=y, IPV4=n, NETLABEL=y a valid configuration. netlbl_mgmt_protocols()
is unchanged at the end of the series.

Wrapping the CIPSOv4 block in #if IS_ENABLED(CONFIG_CIPSO) would not be
enough by itself. The resume state in cb->args[0] uses fixed indices, and
the CALIPSO step checks protos_sent == 2, so skipping the CIPSOv4 step
would also stop CALIPSO from being reported.

Could netlbl_mgmt_protocols() always increment protos_sent for each step,
and only emit the message when that protocol is enabled?

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260930135334.4739-1-fmancera%40suse.de

  reply	other threads:[~2026-10-04 17:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260930135334.4739-1-fmancera@suse.de>
2026-09-30 13:52 ` [PATCH 01/16 net-next v3] ipv4: introduce CONFIG_IPV4 to decouple the IPv4 stack Fernando Fernandez Mancera
2026-09-30 13:52 ` [PATCH 02/16 net-next v3] net: core: add IPv4 fallback stubs and guards for CONFIG_IPV4=n Fernando Fernandez Mancera
2026-10-04 17:22   ` netdev-bot+sashiko
2026-09-30 13:52 ` [PATCH 03/16 net-next v3] net: inet: relocate ip_generic_getfrag and guard IPv4 socket logic Fernando Fernandez Mancera
2026-10-04 17:22   ` netdev-bot+sashiko
2026-09-30 13:52 ` [PATCH 04/16 net-next v3] tcp: move protocol agnostic TCP functions out of tcp_ipv4.c Fernando Fernandez Mancera
2026-10-04 17:22   ` netdev-bot+sashiko
2026-09-30 13:52 ` [PATCH 05/16 net-next v3] ipv4: raw: split IPv4 specific logic into raw_ipv4.c Fernando Fernandez Mancera
2026-10-04 17:22   ` netdev-bot+sashiko
2026-09-30 13:52 ` [PATCH 06/16 net-next v3] ipv4: udp: split IPv4 specific logic into udp_ipv4.c Fernando Fernandez Mancera
2026-10-04 17:22   ` netdev-bot+sashiko
2026-09-30 13:52 ` [PATCH 07/16 net-next v3] ipv4: icmp: split IPv4 specific logic into icmp_ipv4.c Fernando Fernandez Mancera
2026-10-04 17:22   ` netdev-bot+sashiko
2026-09-30 13:52 ` [PATCH 08/16 net-next v3] ipv4: ping: split IPv4 specific logic into ping_ipv4.c Fernando Fernandez Mancera
2026-09-30 13:52 ` [PATCH 09/16 net-next v3] ipv4: fib: split common nexthop logic to fib_core.c Fernando Fernandez Mancera
2026-10-04 17:22   ` netdev-bot+sashiko
2026-09-30 13:52 ` [PATCH 10/16 net-next v3] tunnels: guard IPv4 tunnel functions with CONFIG_IPV4 Fernando Fernandez Mancera
2026-09-30 13:52 ` [PATCH 11/16 net-next v3] ipv4: disable IPv4-only sysctls when CONFIG_IPV4=n Fernando Fernandez Mancera
2026-10-04 17:22   ` netdev-bot+sashiko
2026-09-30 13:52 ` [PATCH 12/16 net-next v3] netfilter: ipv4: guard ip_route_me_harder() with CONFIG_IPV4 Fernando Fernandez Mancera
2026-09-30 13:52 ` [PATCH 13/16 net-next v3] net: bridge: guard ARP/RARP proxy and suppression " Fernando Fernandez Mancera
2026-09-30 13:52 ` [PATCH 14/16 net-next v3] wifi: mac80211: replace CONFIG_INET with CONFIG_IPV4 guards Fernando Fernandez Mancera
2026-09-30 13:52 ` [PATCH 15/16 net-next v3] netlabel: cipso: introduce CONFIG_CIPSO to decouple IPv4 dependency Fernando Fernandez Mancera
2026-10-04 17:22   ` netdev-bot+sashiko [this message]
2026-09-30 13:52 ` [PATCH 16/16 net-next v3] ipv4: make CONFIG_IPV4 boolean Fernando Fernandez Mancera
2026-10-04 17:22   ` 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=179113455547.434549.7410696405500353621@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=fmancera@suse.de \
    --cc=horms@kernel.org \
    --cc=johannes@sipsolutions.net \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®