nft_bandwidth.ko corrupts ext4 rootfs at runtime on kernel 6.12 (feature/openwrt-2512-bump)

[ispyisail]

Summary

nft_bandwidth.ko (from netfilter-match-modules/nftables/bandwidth/) corrupts the ext4 rootfs at runtime when loaded on kernel 6.12.94 (the kernel this branch builds against). This blocks booting any x86 ext4-combined image built from this branch with the module enabled — confirmed with the vnet-wifi profile, likely affects any profile that loads it.

nft_webmon.ko and nft_weburl.ko are confirmed not affected — isolated individually, both boot clean.

Evidence

Built x86.vnet-wifi from this branch (commit c817dfd), kernel 6.12.94. First boot corrupts within ~7 seconds:

EXT4-fs error (device vda2): ext4_lookup:1821: inode #91: comm find: deleted inode referenced: 2400
EXT4-fs (vda2): Remounting filesystem read-only
Failed to execute /usr/libexec/login.sh

(A repeat run against a different inode showed __ext4_new_inode:1282: comm ln: failed to insert inode 2395: doubly allocated? — same bug class, different inode, confirming it's not a one-off.)

Bisection: the same profile/package set built against the pre-bump kernel (6.6.143) boots perfectly clean. Kernel-version-specific.

Module isolation (loop-mounted the built image, moved .ko files + /etc/modules.d/45-nft-* entries aside one at a time, re-booted each combination — no rebuild needed):

Module active alone	Result
nft_bandwidth	Corrupts (same signature)
nft_webmon	Boots clean
nft_weburl	Boots clean

Static filesystem inspection (e2fsck -fy, repeated passes) found nothing wrong at rest — the corruption happens live, during first-boot write activity, not baked into the built image.

Note on c817dfd

That commit (mine, same day) fixes GCC implicit-declaration warnings so these modules compile cleanly on the newer toolchain this branch uses. It does not touch runtime logic and is unrelated to this bug — this corruption is a pre-existing issue in nft_bandwidth.c that simply never had a kernel 6.12 build to run on until now.

Suspected area (not confirmed)

nft_bandwidth.c's init() calls nf_register_sockopt() with hardcoded constants (BANDWIDTH_SET=2048/BANDWIDTH_GET=2049) — an old-style setsockopt/getsockopt registration mechanism. It's the only one of the three modules using this pattern, which lines up with the isolation result, but no collision or root cause has been confirmed yet. The packet-eval path and netlink attribute parsing haven't been fully audited against 6.6→6.12 kernel API changes.

Recommendation

Treat nft_bandwidth as unsafe on kernel 6.12 until root-caused. nft_webmon/nft_weburl can ship/be tested independently.

[ispyisail]

Root cause found and fixed

nft_bandwidth declared 17 netlink attributes (NFTA_BANDWIDTH_MAX), one over the 16-attribute limit (NFT_EXPR_MAXATTR) that kernel 6.12 added to nft_register_expr(): WARN_ON_ONCE(type->maxattr > NFT_EXPR_MAXATTR). That check doesn't exist on kernel 6.6 (confirmed by diffing net/netfilter/nf_tables_api.c between the v6.6 and v6.12 kernel tags directly), which is exactly why this only shows up on this branch's 25.12 kernel bump.

The registration failure alone would just mean "module doesn't load" -- but init() calls nf_register_sockopt() before attempting nft_register_expr(), and never rolled that back on failure. When a module's init() returns nonzero, the kernel doesn't call its exit/fini function and unloads the module's code -- leaving the kernel's global sockopt table (BANDWIDTH_SET=2048, BANDWIDTH_GET=2049) pointing at freed memory. Any later setsockopt/getsockopt on those commands (the exact interface Gargoyle's own userspace bandwidth/quota tooling uses) jumps into that freed memory -- in every reproduction, the resulting corruption landed on ext4 metadata, producing the "doubly allocated" / "deleted inode referenced" errors and an unbootable image.

Confirmed via QEMU monitor screendumps, module-by-module boot isolation (nft_webmon/nft_weburl were never affected, confirmed independently), and a live serial-console insmod reproduction that surfaced the actual WARN_ON_ONCE with a full kernel stack trace.

Fixed in b0fed6c (on top of 1ced149, abeac4e):

• init() now unregisters the sockopt if registration fails, preventing the dangling pointer regardless of attribute count.
• Removed NFTA_BANDWIDTH_MINUTESWEST (dead on the kernel side, never read; had userspace libnftnl plumbing that's now cleaned up in sync) to bring the attribute count to exactly 16.

Verified: with only nft_bandwidth enabled, the vnet-wifi x86 image now boots clean on kernel 6.12.94 -- lsmod shows it loaded and registered under nf_tables, no WARNING, no ext4 errors, writes succeed post-boot.

Closing.

[ispyisail]

The fix for this landed in the reverted+relanded 25.12 bump PR: #43 (supersedes the original #41). Verified this session with a genuine from-scratch build + boot test on all 4 primary targets, not just x86.