BUG/MINOR: cli: fix too many args detection for commands
authorAurelien DARRAGON <adarragon@haproxy.com>
Wed, 7 May 2025 23:01:28 +0000 (01:01 +0200)
committerWilly Tarreau <w@1wt.eu>
Thu, 15 May 2025 15:01:43 +0000 (17:01 +0200)
commit71f72809886476e5cf3bf77631324e2d6b89071f
treed9e49ac2dde1cdff4dc232c57df0d4d5c2c44be7
parenta3343abd2cce9e72f2db1cb1e8a80b277a769fd7
BUG/MINOR: cli: fix too many args detection for commands

d3f928944 ("BUG/MINOR: cli: Issue an error when too many args are passed
for a command") added a new check to prevent the command to run when
too many arguments are provided. In this case an error is reported.

However it turns out this check (despite marked for backports) was
ineffective prior to 20ec1de21 ("MAJOR: cli: Refacor parsing and
execution of pipelined commands") as 'p' pointer was reset to the end of
the buffer before the check was executed.

Now since 20ec1de21, the check works, but we have another issue: we may
read past initialized bytes in the buffer because 'p' pointer is always
incremented in a while loop without checking if we increment it past 'end'
(This was detected using valgrind)

To fix the issue introduced by 20ec1de21, let's only increment 'p' pointer
if p < end.

For 3.2 this is it, now for older versions, since d3f928944 was marked for
backport, a sligthly different approach is needed:

 - conditional p increment must be done in the loop (as in this patch)
 - max arg check must moved above "fill unused slots" comment where p is
   assigned to the end of the buffer

This patch should be backported with d3f928944.

(cherry picked from commit 976e0bd32f6d87fccf351edf1b5a18f3e0c5c6ab)
Signed-off-by: Willy Tarreau <w@1wt.eu>
src/cli.c