shreemaan-abhishek opened a new pull request, #13483:
URL: https://github.com/apache/apisix/pull/13483
### Description
The redis xRPC protocol parser reads the RESP array header (`*<n>\r\n`) from
the
downstream client and passes the declared argument count straight into
`core.tablepool.fetch("xrpc_redis_cmd_line", narg, 0)`. `table.new(n, 0)`
eagerly
allocates `n` array slots, so a large declared count forces a large upfront
allocation before any argument is actually read, regardless of how much data
the
client sends.
This PR bounds and validates the declared argument count:
- The declared count is validated to be a positive integer. Previously a
negative
or non-integer value (e.g. `*-1\r\n`) flowed into `table.new(-1, 0)` and
raised
an uncaught Lua error; it is now rejected cleanly with
`invalid argument number: <n>`.
- The declared count is now used only as a bounded preallocation hint
(clamped to `MAX_CMD_LINE_PREALLOC = 64`). The command-line table still
grows
naturally as the real arguments are read, so legitimate large commands are
unaffected; only the eager preallocation is capped.
This is a behaviour-hardening change to the redis xRPC command parser.
#### Which issue(s) this PR fixes:
Fixes #
### Checklist
- [x] I have explained the need for this PR and the problem it solves
- [x] I have explained the changes or the new features added to this PR
- [x] I have added tests corresponding to this change
- [ ] I have updated the documentation to reflect this change
- [x] I have verified that this change is backward compatible (If not,
please discuss on the [APISIX mailing
list](https://github.com/apache/apisix/tree/master#community) first)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
