Hi Vastargazing,

(+cc Florian who did a similar review on netfilter ML)

On 01/05/2026 17:14, Vastargazing wrote:

Add mptcp_v6_initcall.sh to verify that MPTCP IPv6 subflow child
sockets are allocated from the TCPv6 SLAB cache, not the kmalloc-4k
fallback.

tcpv6_prot_override must copy tcpv6_prot after proto_register(&tcpv6_prot)
populates tcpv6_prot.slab. If the copy runs too early, override.slab
stays NULL (frozen by __ro_after_init) and subflow children fall back
to kmalloc-4k. This lacks SLAB_TYPESAFE_BY_RCU, allowing lockless
ehash lookups in __inet_lookup_established to read freed memory.

The test exercises the IPv6 accept path via MPTCP connections between
two network namespaces, then checks that the TCPv6 slab active object
count grew. On a fixed kernel, the delta is ~2 * NR_CONNS (one subflow
per side per connection); on a broken kernel, it stays near zero because
children land in kmalloc-4k instead.

Topology: two netns connected via veth pair with /64 ULA addresses;
NR_CONNS parallel short-lived MPTCP connections are established and held
open long enough to sample /proc/slabinfo. The test skips if
CONFIG_MPTCP_IPV6 is absent (checked via kallsyms) or /proc/slabinfo is
unreadable.

Verified on Ubuntu 6.17 kernel predating the fix: TAP "not ok 1 ...
TCPv6 slab gains MPTCPv6 subflow children" with delta=0. On kernels
with the fix, delta is well above the threshold of NR_CONNS/2.

Thank you for adding this new test, and for having validated
9b55b253907e ("mptcp: fix slab-use-after-free in
__inet_lookup_established").

(...)

My following review comments are very similar to the ones shared by
Florian for another on the Netfilter ML.

This should say '755', else you get

  # Warning: file mptcp_v6_initcall.sh is not executable

(Plus our CI will not validate that test.)

Me too, I'm not sure whether we should add regression tests for
regression tests sake. Else we'll also quickly accumulate thousands of
such scripts and test run time will explode. Globally, we prefer adding
a new subtest instead of a full test.

Here, you are validating an issue in the init code, that is very
unlikely to change. If a test was needed during the submission of the
original fix, I would have suggested adding a quick test in our
packetdrill repo instead:

  https://github.com/multipath-tcp/packetdrill

An existing packetdrill test could be modified to check the slabs in v4
and v6, but I'm still not convinced it is worth it.

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.