From: sashiko-bot@kernel.org
Cc: linux-security-module@vger.kernel.org
Subject: Re: [PATCH net] calipso: keep BIG TCP payload_len in calipso_skbuff_setattr()
Date: Fri, 09 Oct 2026 15:28:47 +0000 [thread overview]
Message-ID: <sashiko-outbox-165775@kernel.org> (raw)
In-Reply-To: <179147330473.58090.15760316487710432833@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] calipso: skips payload_len update for non-GSO empty packets
--
commit 453f949afc807f64bbb4a0d488ed6f38254f5d88
Author: Joas Antonio dos Santos <joasantonio108@gmail.com>
calipso: keep BIG TCP payload_len in calipso_skbuff_setattr()
This commit prevents calipso_skbuff_setattr() from modifying payload_len
for BIG TCP packets, which natively use a payload_len of 0. It avoids
overwriting the 0 value when adjusting the length for CALIPSO options,
ensuring that ipv6_payload_len() falls back to skb->len properly.
> diff --git a/net/ipv6/calipso.c b/net/ipv6/calipso.c
> index c6a34334e657e..dfea7ed65afc4 100644
> --- a/net/ipv6/calipso.c
> +++ b/net/ipv6/calipso.c
[ ... ]
> @@ -1357,8 +1357,9 @@ static int calipso_skbuff_setattr(struct sk_buff *skb,
> sizeof(*ip6_hdr) + start);
> skb_reset_network_header(skb);
> ip6_hdr = ipv6_hdr(skb);
> - payload = ntohs(ip6_hdr->payload_len);
> - ip6_hdr->payload_len = htons(payload + len_delta);
> + /* BIG TCP packets have payload_len == 0 */
> + if (ip6_hdr->payload_len)
> + be16_add_cpu(&ip6_hdr->payload_len, len_delta);
[Severity: Medium]
Does this conditional skip updating payload_len for non-GSO empty IPv6
packets when adding CALIPSO options?
If a user application sends a 0-byte payload using an IPv6 raw socket
(e.g., IPPROTO_NONE), and a SELinux NetLabel policy applies CALIPSO to the
socket, the NF_INET_LOCAL_OUT hook triggers calipso_skbuff_setattr().
The function will insert the CALIPSO option but leave payload_len as 0.
This results in a packet being transmitted with an IPv6 payload_len of 0
but without a Jumbo Payload option, which RFC 8200 compliant receivers
will discard as malformed.
On a Linux host, this causes ip6_rcv_core() to skip trimming the SKB,
mistakenly passing L2 padding up to the receiving application as payload
data.
> }
>
> hop = (struct ipv6_opt_hdr *)(ip6_hdr + 1);
--
Sashiko AI review · https://sashiko.dev/#/patchset/179147330473.58090.15760316487710432833@gmail.com?part=1
prev parent reply other threads:[~2026-10-09 15:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 15:28 [PATCH net] calipso: keep BIG TCP payload_len in calipso_skbuff_setattr() Joas Antonio dos Santos
2026-10-09 8:46 ` Wang Zhan
2026-10-09 15:57 ` 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-165775@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 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.