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?
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.
