Re: [BUG] netfilter: IPv6 conntrack fragment reassembly truncates header offset

[Pablo Neira Ayuso <pablo@netfilter.org>]

Hi,

We have a patch for this.

But I stumbled a few times over it because I did not have a
reproducer.

If you can share it with me, that would great. Thanks.

On Tue, Sep 29, 2026 at 02:07:58PM +0900, 성병찬 wrote:
> Hello,
> 
> I found a reproducible IPv6 conntrack fragment reassembly bug in:
> 
>   net/ipv6/netfilter/nf_conntrack_reasm.c
> 
> Tested kernel:
> 
>   Linux v7.2.8
>   commit: 9a66fdc0d7fd55f54235524a73435af99051e46f
>   architecture: x86_64
>   KASAN and KCOV enabled
> 
> The problem appears to be in find_prev_fhdr():
> 
>   u8 prev_nhoff = netoff + offsetof(struct ipv6hdr, nexthdr);
> 
> A valid IPv6 extension-header chain can place the previous Next Header
> field at offset 256. Since prev_nhoff is u8, the value is truncated from
> 256 to 0.
> 
> The truncated value is later stored as the fragment queue nhoffset.
> During reassembly, nf_ct_frag6_reasm() consequently modifies byte 0 of
> the IPv6 header instead of the Next Header field at offset 256.
> 
> Observed results with the unmodified kernel:
> 
>   - Control packet with predecessor offset 248: delivered
>   - Boundary packet with predecessor offset 256: not delivered
>   - Ip6InHdrErrors increased by 1
>   - The result was reproduced twice
> 
> I then changed the local variable from u8 to int:
> 
>   - u8 prev_nhoff;
>   + int prev_nhoff;
> 
> Observed results with the modified kernel:
> 
>   - Control packet: delivered
>   - Boundary packet: delivered
>   - Ip6InHdrErrors did not increase
>   - The result was reproduced twice
> 
> I also tested the boundary packet against an IPv6 INPUT firewall rule.
> The packet was counted by both ACCEPT and DROP rules, and no firewall
> bypass was observed.
> 
> No KASAN report, memory corruption, information disclosure, privilege
> escalation, or firewall bypass was observed. I am therefore reporting
> this as a packet corruption/drop correctness bug, not as a confirmed
> security vulnerability.
> 
> The same u8 declaration appears to remain in the current mainline
> source.
> 
> The code appears to have originated from commit:
> 
>   6b88dd966b42e374dc783c397efc15f5c1458265
>   ("[SK_BUFF] ipv6: Use skb_network_offset in some more places")
> 
> I have a minimal C reproducer, kernel configuration, serial logs, and
> before/after test results available. Please let me know if you would
> like me to send the reproducer or prepare a formal patch.
> 
> Regards,
> sungbyeongchan