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

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

[xelra]

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.

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.

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

[Pablo Neira Ayuso]

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.
> 
>