From: 성병찬 <tjdqudcks0424@naver.com>
To: <netfilter-devel@vger.kernel.org>
Cc: <pablo@netfilter.org>, <fw@strlen.de>, <phil@nwl.cc>
Subject: [BUG] netfilter: IPv6 conntrack fragment reassembly truncates header offset
Date: Tue, 29 Sep 2026 14:34:07 +0900 [thread overview]
Message-ID: <622191c6a9b35335b65fdb07f8914b7@cweb016.nm> (raw)
Hello,
Resending in plain text because the mailing list rejected my previous
message.
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
x86_64 with KASAN enabled
In find_prev_fhdr(), the previous Next Header offset is stored in u8:
u8 prev_nhoff = netoff + offsetof(struct ipv6hdr, nexthdr);
A valid IPv6 extension-header chain can place this field at offset 256.
The value is then truncated to 0. During fragment reassembly,
nf_ct_frag6_reasm() modifies IPv6 header byte 0 instead of the Next
Header field at offset 256.
Results with the unmodified kernel, reproduced twice:
control offset 248: delivered
boundary offset 256: dropped
Ip6InHdrErrors: increased by 1
I changed prev_nhoff from u8 to int and repeated the test twice:
control offset 248: delivered
boundary offset 256: delivered
Ip6InHdrErrors: unchanged
No KASAN report, memory corruption, information disclosure, privilege
escalation, or firewall bypass was observed. I am reporting this as a
packet corruption/drop correctness bug.
The same u8 declaration appears to remain in current mainline.
I have a minimal C reproducer, configuration, logs, and before/after
results available.
Regards,
sungbyeongchan
next reply other threads:[~2026-09-29 5:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 5:34 성병찬 [this message]
2026-09-29 7:20 ` [BUG] netfilter: IPv6 conntrack fragment reassembly truncates header offset Florian Westphal
2026-09-29 9:07 ` Pablo Neira Ayuso
[not found] <31da96413a406da2116f44df2db84f@cweb009.nm>
2026-09-29 9:01 ` Pablo Neira Ayuso
2026-09-29 9:14 ` 성병찬
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=622191c6a9b35335b65fdb07f8914b7@cweb016.nm \
--to=tjdqudcks0424@naver.com \
--cc=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
/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