On 29/10/2026 11:29, Florian Westphal wrote:
Uwe Kleine-König <[email protected]> wrote:
this is about a bug report filed against the Debian 7.2.12 kernel. Further
context can be found at https://bugs.debian.org/1149525.
Note this is an arm64 machine, and the problem doesn't reproduce on 7.3.
On Mon, Oct 26, 2026 at 08:36:01AM +0100, Philip Dodd wrote:
7.2.12+deb14-arm64 is affected in the same way, reproduced by just loading
the nf_conntrack module shortly after boot.
After the failure:
nf_conntrack module use count: 0
net.netfilter.nf_conntrack_count: 0
nf_conntrack hashsize: 65536
/proc/sys/kernel/tainted: 128
No nf_nat or xt_* modules were loaded.
If thats the case, why is there a conntrack entry in the first place?
Is 'enable_hooks' modparam used?
No, I'm not explicitly using |enable_hooks|. Simply running |sudo
modprobe nf_conntrack|is sufficient to trigger the oops.
For context, I originally encountered the oops shortly after boot during
normal operation. I narrowed it down to occurring shortly after
|tailscaled|started, but subsequently found that even with Tailscale
disabled, simply loading |nf_conntrack|triggers the same oops almost
immediately; and since I've reproduced this on all the 7.2.x kernels
I've tested (the versions mentioned earlier in the Debian bug report),
but also kernels compiled directly from upstream sources.
The same |modprobe nf_conntrack|command does not trigger the oops on
7.1.x or 7.3.x kernels; Prior to upgrading to the first 7.2.x kernel,
this host had also been running Tailscale with |nf_conntrack|loaded for
weeks (at least) without any problems and yesterday, I installed the
7.3.x kernel packages from Debian experimental and ran Tailscale for an
extended period without encountering any issues.
So, as far as I can establish, this is an issue specific to the 7.2.x
series, with the issue no longer reproducible on 7.3.x.
If not, conntrack hooks are not registered so it cannot pick up
any entries (you need some rules configured that require conntrack
without that modparam on).
That would imply that hlist_nulls_for_each_entry_rcu() is causing loop
execution for an empty list.
The problematic code location is
if (nf_ct_is_expired(tmp)) {
in net/netfilter/nf_conntrack_core.c with
static inline bool nf_ct_is_expired(const struct nf_conn *ct)
{
return (__s32)(READ_ONCE(ct->timeout) - nfct_time_stamp) <= 0;
}
.
In assembly that is:
2f78: 9a812000 csel x0, x0, x1, cs // cs = hs, nlast
2f7c: cb1c0000 sub x0, x0, x28
2f80: 9ada0c00 sdiv x0, x0, x26
2f84: 8b00039c add x28, x28, x0
2f88: f94042e0 ldr x0, [x23, #128]
2f8c: 37180300 tbnz w0, #3, 2fec <gc_worker+0x184>
2f90: f9400318 ldr x24, [x24]
2f94: 37000a78 tbnz w24, #0, 30e0 <gc_worker+0x278>
2f98: 3940df00 ldrb w0, [x24, #55]
2f9c: 9ba98800 umsubl x0, w0, w9, x2
2fa0: 8b000317 add x23, x24, x0
* 2fa4: b9400ae1 ldr w1, [x23, #8]
2fa8: f940036b ldr x11, [x27]
I think the original issue was a few lines above (i.e.
ldrb w0, [x24, #55]), because the tripping address was 0000000000010037
(with 55 = 0x37). That is in nf_ct_tuplehash_to_ctrack(h).
All in all it looks like `h` is invalid.
Its a garbage address, yes.
Does that ring a bell? After starring at the code for a while I don't
spot the culprit. Also looking over the changes between 7.2.12 and 7.3
I don't spot a suspicious commit.
Never seen this before.
