In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfnat: avoid invalid natnet pointer use on failed nfnatinit()

We ran into below KASAN splat, which is mostly uninteresting, beside for having nfnatregister_fn() in the call chain as a cause for the offending access:

================================================================== BUG: KASAN: slab-out-of-bounds in nfnatregister_fn+0x5f9/0x640 Read of size 8 at addr ffff890031e54c20 by task iptables/9510

CPU: 0 UID: 0 PID: 9510 Comm: iptables Not tainted 6.18.18-grsec-full-20260320181326 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> […] dumpstacklvl+0xee/0x160 ffff88004117eeb8 […] print_report+0x6e/0x640 ffff88004117eee0 […] ? __physaddr+0x8e/0x140 ffff88004117eef0 […] ? kasanaddrtoslab+0x51/0xe0 ffff88004117ef08 […] ? completereportinfo+0xec/0x1c0 ffff88004117ef20 […] ? nfnatregisterfn+0x5f9/0x640 ffff88004117ef48 […] kasanreport+0xbc/0x140 ffff88004117ef50 […] ? nfnatregisterfn+0x5f9/0x640 ffff88004117ef90 […] nfnatregisterfn+0x5f9/0x640 ffff88004117eff8 […] ? nfnaticmpreplytranslation+0x6e0/0x6e0 ffff88004117f070 […] nftablesregisterhook.part.0+0xa0/0x220 ffff88004117f080 […] nftablesaddchain.constprop.0+0x1054/0x1fc0 ffff88004117f0b8 […] ? nftchainlookup.part.0+0x4ce/0xac0 ffff88004117f130 […] ? nftablesabort+0x3d80/0x3d80 ffff88004117f190 […] ? nftablesdumpresetobj+0x100/0x100 ffff88004117f1c8 […] ? nfttablelookup.part.0+0x255/0x300 ffff88004117f310 […] ? nftablesnewchain+0x21a4/0x2fa0 ffff88004117f358 […] nftablesnewchain+0x21a4/0x2fa0 ffff88004117f360 […] ? nftablesaddchain.constprop.0+0x1fc0/0x1fc0 ffff88004117f458 […] ? nlagetrangesigned+0x4a0/0x4a0 ffff88004117f488 […] ? lockacquire+0x16f/0x320 ffff88004117f490 […] ? findheldlock+0x3b/0xe0 ffff88004117f4b0 […] ? __nlaparse+0x45/0x80 ffff88004117f500 […] nfnetlinkrcvbatch+0xbca/0x19a0 ffff88004117f550 […] ? nfnetlinknetexitbatch+0x120/0x120 ffff88004117f618 […] ? __sanitizercovtraceswitch+0x63/0xe0 ffff88004117f720 […] ? graclhandlemmap+0x1c4/0x320 ffff88004117f7c0 […] ? nlagetrangesigned+0x4a0/0x4a0 ffff88004117f7e8 […] ? gris_capable+0x6f/0xe0 ffff88004117f830 […] ? __nlaparse+0x45/0x80 ffff88004117f860 […] ? skbpull+0x103/0x1a0 ffff88004117f880 […] nfnetlinkrcv+0x3db/0x4a0 ffff88004117f8b0 […] ? nfnetlinkrcvbatch+0x19a0/0x19a0 ffff88004117f8d8 […] ? netlinklookup+0xe2/0x240 ffff88004117f900 […] netlinkunicast+0x74b/0xb00 ffff88004117f930 […] ? netlinkattachskb+0xb20/0xb20 ffff88004117f980 […] ? __checkobjectsize+0x3e/0xaa0 ffff88004117f998 […] ? security_netlinksend+0x51/0x160 ffff88004117f9c8 […] netlinksendmsg+0xa03/0x1200 ffff88004117f9f8 […] ? netlinkunicast+0xb00/0xb00 ffff88004117fa70 […] ? netlinkunicast+0xb00/0xb00 ffff88004117fac8 […] ? ____sys_sendmsg+0xe2a/0x1040 ffff88004117faf8 […] ____syssendmsg+0xe2a/0x1040 ffff88004117fb00 […] ? kernelrecvmsg+0x300/0x300 ffff88004117fb60 […] ? reacquireheldlocks+0xe9/0x260 ffff88004117fbc8 […] ___syssendmsg+0x138/0x200 ffff88004117fbf8 […] ? dorecvmmsg+0x7e0/0x7e0 ffff88004117fc30 […] ? lockdephardirqsonprepare+0x101/0x1e0 ffff88004117fc50 […] ? lockacquire+0x16f/0x320 ffff88004117fd20 […] ? lockacquire+0x16f/0x320 ffff88004117fd58 […] ? findheld_lock+0x3b/0xe0 ffff88004117fd70 […] __sys_sendmsg+0x17a/0x260 ffff88004117fdc8 […] ? __syssendmsgsock+0x80/0x80 ffff88004117fdf0 […] ? syscalltraceenter+0x15e/0x2c0 ffff88004117fe98 […] dosyscall64+0x7d/0x400 ffff88004117fec8 […] entrySYSCALL64safestack+0x4a/0x60 ffff88004117fef8

</TASK>

The out-of-bounds report, though, is a red herring as it is f ---truncated---