Re: [PATCH net] calipso: keep BIG TCP payload_len in calipso_skbuff_setattr()

[Joas Antonio dos Santos <joasantonio108@gmail.com>]

On Fri, 09 Oct 2026, Wang Zhan wrote:
> I think there are boundary cases around IPV6_MAXPLEN: growing past it
> can cause payload_len to overflow, while shrinking below it leaves
> payload_len at zero.
>
> Could we use ipv6_set_payload_len(ip6_hdr, skb->len - sizeof(*ip6_hdr))
> to set the length here? I haven't checked the details, though.

Hi Wang,

You are right on both.  I checked them with a test-only debugfs hook
calling netlbl_skbuff_setattr() with a level-only label:

  case                         v1 (this patch)   your suggestion   real
  65530 GSO, grows past MAXPLEN            10           0          65546
  65540 GSO, shrinks below MAXPLEN          0       65532          65532

(0 meaning ipv6_payload_len() falls back to skb->len.)  The other cases
(normal packet, BIG TCP growing, shrinking a normal packet) give the
same result either way.  skb->len - sizeof(*ip6_hdr) is the payload
length there, as the network header was just reset to skb->data.

I will send v2 with ipv6_set_payload_len() and the test table once the
24h are up.

calipso_skbuff_delattr() (the other patch, v2 already posted) only
shrinks, so it cannot overflow; it can leave 0 when a BIG TCP packet
drops below IPV6_MAXPLEN, which ipv6_payload_len() still handles.  I
can switch it to the same helper for consistency if preferred.

Thanks,
Joas