Re: [PATCH net] netfilter: nf_conntrack_reasm: avoid truncating header offset

[tjdqudcks0424@naver.com]

From: Sung Byeongchan <tjdqudcks0424@naver.com>

Hi,

Resending in plain text because my previous webmail reply was rejected by
the mailing lists for containing an HTML part.

I independently tested the 16-bit header-offset concern raised in this
review. The concern is valid and can cause a local kernel panic.

This is separate from the existing prev_nhoff u8 truncation issue. To
isolate the two issues, I tested a current-mainline-based kernel at:

  ce1e0223d8ad4211275c82a17ed6d43ab81e13d9

with only the already-public u8-to-int prev_nhoff fix applied.

The reproducer sends a 65536-byte IPV6_HDRINCL packet to ::1 with the
real Fragment Header at fhoff=65528. The loopback raw-output path
reserves 16 bytes of headroom, so:

  headroom + fhoff = 16 + 65528 = 65544

This value is stored in the u16 skb->transport_header field and wraps
to 8.

With init_on_alloc=1, the wrapped pointer reads the zeroed headroom as
a Fragment Header with offset 0 and MF clear. Reassembly completes,
advances network_header from 16 to 24 while skb->data remains at 16,
and inet_frag_reasm_finish() passes -8 as the unsigned length to
skb_push().

The resulting diagnostic is:

  skbuff: skb_under_panic: ... len:65520 put:-8 ...
  kernel BUG at net/core/skbuff.c
  skb_push
  inet_frag_reasm_finish
  nf_ct_frag6_gather
  ipv6_defrag
  rawv6_sendmsg
  Kernel panic - not syncing: Fatal exception in interrupt

I reproduced the panic in three isolated QEMU runs:

  1. Linux v7.2.8 as root
  2. The mainline-based u8-fixed baseline as root
  3. The same mainline-based baseline from outer UID 65534 after
     entering a new user and network namespace

In the third case, the process had CAP_NET_RAW only inside its new
user and network namespace. No loopback MTU change was required.

The crash runs used nf_conntrack.enable_hooks=1 to activate IPv6
conntrack defragmentation. I confirmed from the source that an nftables
ct expression can also acquire the IPv6 defrag hook in the caller's
network namespace, but I did not perform an additional crash run using
only that activation method.

I tested the following minimal guard on top of the public u8 fix:

  if (nhoff != (u16)nhoff ||
      !skb_set_transport_header_careful(skb, fhoff))
          return -EINVAL;

With an otherwise identical KASAN configuration:

  - the exact crash packet was safely rejected in 3/3 runs;
  - short fragmented packets passed in 3/3 runs;
  - the previous offset-248 and offset-256 cases passed in 3/3 runs;
  - ordinary IPv6 UDP and TCP passed in 3/3 runs;
  - no KASAN, WARNING, BUG, Oops, or panic was observed.

I searched current mainline history, lore, Patchwork, and
linux-cve-announce. I found the existing prev_nhoff u8 fix, but did not
find an existing patch or commit that checks the u16 nhoff storage or
uses skb_set_transport_header_careful() in this path.

The demonstrated impact is a local kernel-wide denial of service when
IPv6 conntrack defragmentation is active. The panic occurs before
packet delivery, so I found no evidence of information disclosure,
privilege escalation, arbitrary memory corruption, or remote
reachability.

Would you prefer this check to be folded into the existing prev_nhoff
patch, or should I submit it as a separate follow-up patch on top of
that change? I have the reproducer, serial logs, A/B results, and an
applyable follow-up patch ready.

Regards,
Sung Byeongchan