Skip to content

[1772] TACDev: bounds-check indexed getters and report GetHelpText size - #136

Open
hangzqcom wants to merge 1 commit into
developfrom
fix/tacdev-bounds-checks
Open

hangzqcom wants to merge 1 commit into
developfrom
fix/tacdev-bounds-checks

Conversation

@hangzqcom

Copy link
Copy Markdown
Contributor

Problem

Several TACDev C API getters trusted the caller's index or left an out-parameter unset:

Function Input Before
GetPortData deviceIndex = -1 / -1000 Host process crashes (negative index into QList::at())
GetCommand index >= GetCommandCount() Returns success with a garbage entry ;;18446744073709551615;;;
GetScriptVariable index >= GetScriptVariableCount() No range check
GetHelpText buffer large enough *actualSize left unset on success

GetCommand relied on commandEntry() returning pin 0 for a bad index. It actually returns a default entry with pin -1, so the existing _pin != 0 check passed.

Change

  • GetPortData: also reject deviceIndex < 0, so it returns 0 like any other invalid index.
  • GetCommand / GetScriptVariable: check the index against the count explicitly. Out of range now returns TAC_BAD_INDEX with an empty buffer, which is what GetQuickCommand already does.
  • GetHelpText: set *actualSize on success too, guarded by the existing null check.

One file, interfaces/C++/TACDev/TACDev.cpp. No header or ABI change.

Valid indexes behave exactly as before. I checked the in-repo callers (C#, Python, Java and MCP examples, TACDump) and they all iterate up to the reported count. None loops until failure, so the new TAC_BAD_INDEX return only affects calls that were already out of range.

Verification

Tested on Windows with a PSoC board (FW 1.4.19.0), using this DLL in the installed tools folder.

  • Direct TACDev API:
    • GetPortData(-1) and GetPortData(-1000) return 0 and the process exits cleanly. Before, it crashed.
    • GetCommand(out of range) and GetScriptVariable(out of range) return TAC_BAD_INDEX (4) with an empty buffer.
    • GetHelpText reports actualSize = 1363, matching the returned length.
    • All valid command, quick-command and script-variable entries are unchanged.
    • 20 open/read/close cycles and 80 read sweeps: no errors.
  • Through TAC Service, which loads TACDev: the read, idempotent-write, destroy/recreate and kill-recovery sequences all pass.
  • Other tools: TAC, TAC Configuration Editor and Device Catalog start normally, and TACDump enumerates the board.

Overall: 165 pass, 0 fail. Before this change the same run had 7 failures, all covered by the table above.

Several TACDev C API getters trusted the caller's index:

- GetPortData() only checked deviceIndex against the upper bound, so a
  negative index was passed to QList::at() and crashed the host
  process (assert in debug, out-of-bounds read in release).
- GetCommand() relied on commandEntry() returning pin 0 for a bad
  index, but it returns a default entry with pin -1, so an
  out-of-range index succeeded and produced a garbage
  ";;18446744073709551615;;;" entry instead of an error.
- GetScriptVariable() did not check the index at all.

Both now return TAC_BAD_INDEX with an empty buffer for an
out-of-range index, the same as GetQuickCommand() already does.
Existing callers iterate up to the reported count, so valid indexes
behave exactly as before.

GetHelpText() set *actualSize only when the buffer was too small. It
now also reports the size on success, as the parameter name implies.

Verified on a PSoC board: negative GetPortData indexes return 0
without crashing, out-of-range GetCommand/GetScriptVariable return
TAC_BAD_INDEX, GetHelpText reports actualSize, and TacService, TACDump
and the TAC GUI tools work unchanged.

Signed-off-by: hangzqcom <hangz@qti.qualcomm.com>
@hangzqcom hangzqcom changed the title TACDev: bounds-check indexed getters and report GetHelpText size [1772] TACDev: bounds-check indexed getters and report GetHelpText size Oct 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant