invalid pointer in nf_conntrack

invalid pointer in nf_conntrack

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 6442 bytes --]

Control: forwarded 1149525 https://lore.kernel.org/netfilter-devel/auDhy6OW5SrGg3jv@monoceros

Hello,

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.
> 
> This time the fault occurred on CPU 1 rather than CPU 4. The faulting
> address is 0xfff8, with x24 again containing 0x10000.
> 
> Trace :
> 
> [  234.152118] Unable to handle kernel paging request at virtual address 000000000000fff8
> [  234.152884] Mem abort info:
> [  234.153151]   ESR = 0x0000000096000007
> [  234.153502]   EC = 0x25: DABT (current EL), IL = 32 bits
> [  234.153993]   SET = 0, FnV = 0
> [  234.154283]   EA = 0, S1PTW = 0
> [  234.154580]   FSC = 0x07: level 3 translation fault
> [  234.155031] Data abort info:
> [  234.155302]   ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000
> [  234.155807]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [  234.156343]   GCS = 0, Overlay = 0, DirtyBit = 0
> [  234.156774] user pgtable: 4k pages, 48-bit VAs, pgdp=000000000fdf4000
> [  234.157367] [000000000000fff8] pgd=0800000010988403, p4d=0800000010988403, pud=0800000010987403, pmd=080000000d349403, pte=0000000000000000
> [  234.158531] Internal error: Oops: 0000000096000007 [#1]  SMP
> [  234.159050] Modules linked in: nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 snd_soc_hdmi_codec snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd soundcore dw_hdmi_cec dw_hdmi_i2s_audio gpio_ir_recv hantro_vpu leds_gpio binfmt_misc rockchipdrm panfrost rockchip_vdec dw_hdmi_qp gpu_sched v4l2_jpeg dw_mipi_dsi rockchip_rga drm_shmem_helper dw_hdmi v4l2_vp9 v4l2_h264 videobuf2_dma_contig analogix_dp realtek v4l2_mem2mem videobuf2_dma_sg phy_package videobuf2_memops drm_dp_aux_bus ofpart videobuf2_v4l2 drm_display_helper videodev dwmac_rk spi_nor stmmac_platform rockchip_saradc cec rockchip_thermal stmmac mtd rc_core industrialio_triggered_buffer videobuf2_common drm_client_lib kfifo_buf coresight_cpu_debug drm_dma_helper coresight_etm4x mc industrialio pcs_xpcs drm_kms_helper coresight phylink cpufreq_dt evdev cfg80211 rfkill nf_tables dm_mod efi_pstore configfs ext4 crc16 mbcache jbd2 xhci_plat_hcd xhci_hcd fusb302 tcpm aux_hpd_bridge drm dwc3 reset_gpio rk808_regulator udc_core typec ulpi fan53555 ghash_ce
> [  234.159475]  gpio_rockchip dwc3_of_simple gf128mul pwm_regulator pwm_fan fixed gpio_keys phy_rockchip_inno_usb2 ohci_platform sdhci_of_arasan ehci_platform phy_rockchip_emmc phy_rockchip_pcie sdhci_pltfm io_domain ehci_hcd ohci_hcd sdhci usbcore dw_mmc_rockchip rockchip_dfi pwm_rockchip dw_mmc_pltfm dw_wdt spi_rockchip pl330 phy_rockchip_typec cqhci nvmem_rockchip_efuse dw_mmc usb_common i2c_rk3x autofs4 aes_ce_blk aes_neon_bs
> [  234.170887] CPU: 1 UID: 0 PID: 50 Comm: kworker/1:1 Not tainted 7.2.12+deb14-arm64 #1 PREEMPTLAZY  Debian 7.2.12-1
> [  234.171846] Hardware name: Pine64 RockPro64 v2.1 (DT)
> [  234.172322] Workqueue: events_power_efficient gc_worker [nf_conntrack]
> [  234.173021] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [  234.173652] pc : gc_worker+0x13c/0x780 [nf_conntrack]
> [  234.174191] lr : process_one_work+0x17c/0x4d8
> [  234.174600] sp : ffff800080313d40
> [  234.174905] x29: ffff800080313d40 x28: 0000000000003a98 x27: ffffcb2f7fce6a00
> [  234.175568] x26: 0000000000000064 x25: 0000000000000000 x24: 0000000000010000
> [  234.176238] x23: 000000000000fff0 x22: 00000000000124f7 x21: 000000000000b770
> [  234.176911] x20: ffffcb2f04df7968 x19: ffffcb2f04dfae08 x18: 0000000000000001
> [  234.177587] x17: 000000040044ffff x16: ffffcb2f7d51d7d0 x15: ffffcb2f7fcf2218
> [  234.178263] x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101
> [  234.178938] x11: 7f7f7f7f7f7f7f7f x10: feff736d64686268 x9 : 0000000000000038
> [  234.179613] x8 : 8080000000000000 x7 : ffffcb2f7fce6000 x6 : fefefefefefefeff
> [  234.180291] x5 : ffff000000e44388 x4 : ffffcb2f04df7970 x3 : 0000000000010000
> [  234.180968] x2 : fffffffffffffff0 x1 : 0000000000000000 x0 : fffffffffffffff0
> [  234.181629] Call trace:
> [  234.181862]  gc_worker+0x13c/0x780 [nf_conntrack] (P)
> [  234.182415]  process_one_work+0x17c/0x4d8
> [  234.182790]  worker_thread+0x194/0x2f8
> [  234.183139]  kthread+0x134/0x150
> [  234.183445]  ret_from_fork+0x10/0x20
> [  234.183787] Code: 37000a78 3940df00 9ba98800 8b000317 (b9400ae1)
> [  234.184341] ---[ end trace 0000000000000000 ]---

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.

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.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: invalid pointer in nf_conntrack

[Florian Westphal]

Uwe Kleine-König <ukleinek@debian.org> 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.