[PATCH net v2] calipso: update payload_len when removing the CALIPSO option
Paul Moore
paul at paul-moore.com
Wed Oct 14 14:02:32 UTC 2026
On Fri, Oct 9, 2026 at 11:32 AM <sashiko-bot at kernel.org> wrote:
>
> 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 <joasantonio108 at gmail.com>
>
> 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.
>
> > 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.
> Because bridged packets bypass L3 routing and do not go through
> neigh_output(), the bridge's transmission function br_dev_queue_push_xmit()
> unconditionally calls skb_push(skb, ETH_HLEN). Since skb->data is shifted
> by delta bytes during the pull, this incorrectly frames the transmitted MAC
> header starting delta bytes into the original MAC header.
>
> Could this result in the transmission of gap bytes and the loss of the
> destination MAC address, causing severe packet corruption and drops on
> L2 forwarded packets?
>
> > + ip6_hdr = ipv6_hdr(skb);
> > + /* BIG TCP packets have payload_len == 0 */
> > + if (ip6_hdr->payload_len)
> > + be16_add_cpu(&ip6_hdr->payload_len, -delta);
> > }
> >
> > return 0;
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/179147329205.58079.5847298721173675285@gmail.com?part=1
--
paul-moore.com
More information about the Linux-security-module-archive
mailing list