A mark value of 0x00000001 could appear as 0x01000000 in nft list ruleset even when the kernel was using the intended value. The bytes and the metadata explaining how to display those bytes had diverged.
My patch addressed two paths in the Go nftables library. Anonymous, constant, and interval sets could emit big-endian key metadata even when their key byte order had been explicitly set to native endian. Maps also lacked a way to emit the data byte-order metadata used for their values.
The first correction gave explicit native-endian keys precedence over the set-kind fallback. The second added DataByteOrder and emitted the corresponding userdata value for maps. The decoding path read both key and data byte-order fields back into the Go representation.
Those userdata fields told the nft userspace tool how to reconstruct a human-readable rule. They were not a replacement for the element bytes themselves. Changing the data to compensate for a misleading listing would have risked breaking the behavior that was already correct.
The patch included round-trip system tests for several set and map forms, including preserving the existing big-endian default when no explicit native-endian setting was supplied. The public report also describes the display symptoms for marks and interface-name maps.
The PR remains open as of September 21, 2026.