Re: [PATCH net v2] calipso: update payload_len when removing the CALIPSO option

On 10/14/26 16:02, Paul Moore wrote:

On Fri, Oct 9, 2026 at 11:32 AM [off-list ref] wrote:

quoted

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ipv6: calipso_skbuff_delattr corrupts MAC header on bridged packets
--

commit 9797bee2d14350b4afedb726df3172b004b7badd
Author: Joas Antonio dos Santos [off-list ref]

calipso: update payload_len when removing the CALIPSO option

This commit updates calipso_skbuff_delattr() to adjust the IPv6 payload
length after removing a CALIPSO option. The patch prevents forwarded packets
from being dropped as truncated by subtracting the removed length, while
leaving BIG TCP packets unchanged.

quoted

diff --git a/net/ipv6/calipso.c b/net/ipv6/calipso.c
index c6a34334e657e..5a42db4f87472 100644
--- a/net/ipv6/calipso.c
+++ b/net/ipv6/calipso.c

@@ -1428,6 +1428,10 @@ static int calipso_skbuff_delattr(struct sk_buff *skb)
               skb_pull(skb, delta);
               memmove((char *)ip6_hdr + delta, ip6_hdr, size);
               skb_reset_network_header(skb);

[Severity: High]
When a bridged IPv6 packet with a CALIPSO option is forwarded, br_netfilter
feeds it to the NF_INET_FORWARD hook where SELinux may call
calipso_skbuff_delattr() in net/ipv6/calipso.c. Does shifting the IPv6 header
forward by delta bytes here without repositioning the MAC header create a gap
that corrupts the MAC header on bridged packets?

I haven't chased down the bridging code to confirm if the problem
identified by Sashiko is true, but I do think that in the bridging
case we don't want to change the label on the packet as we might do in
the routing case (depending on the runtime config).

This would need to be tested, but I believe we could simply add a
nf_bridge_info_exists() check to selinux_ip_forward() prior to calling
into selinux_netlbl_skbuff_setsid().  We would need to add dummy
nf_bridge_info_exists() when CONFIG_BRIDGE_NETFILTER=n to
netfilter_bridge.h but I can't imagine the netdev folks being opposed
to such a change; I'm sure they will let us know either way.

The above looks like a pre-exiting issue, the patch itself looks
correct, right?

/P