Linux Security Modules development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
Cc: linux-security-module@vger.kernel.org
Subject: Re: [PATCH net v2] calipso: update payload_len when removing the CALIPSO option
Date: Fri, 09 Oct 2026 15:28:26 +0000	[thread overview]
Message-ID: <sashiko-outbox-165773@kernel.org> (raw)
In-Reply-To: <179147329205.58079.5847298721173675285@gmail.com>

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@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?

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

      reply	other threads:[~2026-10-09 15:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08 15:28 [PATCH net v2] calipso: update payload_len when removing the CALIPSO option Joas Antonio dos Santos
2026-10-09 15:28 ` 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-165773@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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