Re: [nft] 1.1.7: limit rate without burst breaks later tokens

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Tue, Nov 03, 2026 at 08:58:25PM +0000, xelra wrote:
> Hi,
> 
> nftables 1.1.7 fails to parse a rule with a "limit rate" that has no
> "burst", followed by "reject with tcp reset" and anything after it:
> 
>   $ cat repro.nft
>   table inet t {
>     chain c {
>       tcp dport 1 limit rate 5/second reject with tcp reset comment "x"
>     }
>   }
>   $ nft -c -f repro.nft
>   repro.nft:3:59-59: Error: syntax error, unexpected junk
> 
> Column 59 is the "c" of "comment", which the error lists among the
> tokens it expected.
> 
> Without the comment, the next statement fails instead, at "lo" in
> "iif lo accept", even when it's on the next line. The rule parses fine
> with an explicit "burst 5 packets", without the limit, or with an icmpx
> reject instead of the tcp reset.

The scanner updates are bringing issues.

I would suggest a revert of these patches, and make a new release.

Then go back to the whiteboard to see if the scanner can be improved
in a different way.

Unless Phil prefers to go ahead a explore something in the opposite
direction and refine what is already in the tree.

> JUNK for a plain word means the scanner is in SCANSTATE_RATE there,
> the only exclusive start condition. My guess from reading
> scanner_pop_start_cond(): without a burst, bison's lookahead after the
> rate is scanned while SCANSTATE_RATE is active and pushes its own
> scope, so the rate and limit pops are deferred via flex_state_pop. The
> push/pop pairs of TCP and CMD_RESET in "reject with tcp reset" then use
> up that count, and the scanner falls back into SCANSTATE_RATE.
> 
> 1.1.6 parses all of the above. Bisecting points to 9d105581b5f1
> ("scanner: Introduce SCANSTATE_RATE"), and current master
> (07be13393b00) fails the same way. The fix already in 1.1.7, "scanner:
> Accept all statements' first words in all scopes", doesn't cover this
> case.
> 
> Workaround: an explicit burst, or the limit on a jump and the reject in
> its own chain.
> 
>