From: sashiko-bot@kernel.org
Cc: selinux@vger.kernel.org, linux-security-module@vger.kernel.org
Subject: Re: [PATCH] selinux: don't label bridged packets in selinux_ip_forward()
Date: Sat, 17 Oct 2026 14:37:57 +0000 [thread overview]
Message-ID: <sashiko-outbox-175561@kernel.org> (raw)
In-Reply-To: <179216146138.25460.7866279004288174372@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] selinux: NetLabel bypass for routed bridge packets in selinux_ip_forward()
--
commit aa9d29a0c0e705f6d7d92b6c1e12ec004af2b214
Author: Joas Antonio dos Santos <joasantonio108@gmail.com>
selinux: don't label bridged packets in selinux_ip_forward()
This commit avoids labeling bridged IP packets in selinux_ip_forward() to
prevent MAC and EtherType corruption when adding or removing CIPSO or
CALIPSO options. It adds nf_bridge_info_exists() to skip bridged packets
since labeling based on IP addresses is unwanted there.
Link: https://lore.kernel.org/netdev/CAHC9VhS+bdL_YnLQtd0sPmKKfy9BvS-LWV_6EhAuu4qfUFe_mw@mail.gmail.com/
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 18dd28b2bb13d..735e4889bd5b7 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
[ ... ]
> @@ -6021,11 +6022,13 @@ static unsigned int selinux_ip_forward(void *priv, struct sk_buff *skb,
> SECCLASS_PACKET, PACKET__FORWARD_IN, &ad))
> return NF_DROP;
>
> - if (netlbl_enabled())
> - /* we do this in the FORWARD path and not the POST_ROUTING
> - * path because we want to make sure we apply the necessary
> - * labeling before IPsec is applied so we can leverage AH
> - * protection */
> + /* we do this in the FORWARD path and not the POST_ROUTING path
> + * because we want to make sure we apply the necessary labeling
> + * before IPsec is applied so we can leverage AH protection; bridged
> + * packets are skipped as changing their IP options would leave the
> + * Ethernet header behind
> + */
> + if (netlbl_enabled() && !nf_bridge_info_exists(skb))
> if (selinux_netlbl_skbuff_setsid(skb, family, peer_sid) != 0)
> return NF_DROP;
[Severity: High]
Does this logic inadvertently skip NetLabel tagging for packets that are
legitimately routed rather than just bridged?
If a packet arrives on a bridge port, receives the SKB_EXT_BRIDGE_NF extension
in br_nf_pre_routing(), and is destined for the host's MAC address, it is
passed up to the local IP stack via br_pass_frame_up().
Since the bridge extension is not freed on the local input path, the packet
retains it.
When the packet is subsequently L3 forwarded via ip_forward(), the
NF_INET_FORWARD hook calls selinux_ip_forward().
Because nf_bridge_info_exists(skb) evaluates to true for these routed packets,
it appears SELinux will erroneously skip the NetLabel tagging, potentially
allowing a remote or local unprivileged attacker to bypass network security
policies.
--
Sashiko AI review · https://sashiko.dev/#/patchset/179216146138.25460.7866279004288174372@gmail.com?part=1
prev parent reply other threads:[~2026-10-17 14:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 14:37 [PATCH] selinux: don't label bridged packets in selinux_ip_forward() Joas Antonio dos Santos
2026-10-16 19:11 ` Stephen Smalley
2026-10-17 14:37 ` sashiko-bot [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=sashiko-outbox-175561@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=selinux@vger.kernel.org \
/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.