Message-ID: From: "jarvis24young (@jarvis24young)" To: "postgresql-interfaces/psqlodbc" Date: Mon, 11 May 2026 08:59:38 +0000 Subject: [postgresql-interfaces/psqlodbc] PR #185: Avoid reading before leading string literals List-Id: X-GitHub-Author-Id: 48787405 X-GitHub-Author-Login: jarvis24young X-GitHub-Issue: 185 X-GitHub-Repo: postgresql-interfaces/psqlodbc X-GitHub-State: merged X-GitHub-Type: pull_request X-GitHub-Url: https://github.com/postgresql-interfaces/psqlodbc/pull/185 Content-Type: text/plain; charset=utf-8 This fixes a one-byte read before the start of the prepared SQL buffer when parameter counting sees a leading string literal while standard_conforming_strings is on. Call chain reproduced through unixODBC with an ASan build: - SQLPrepare(hstmt, "'abc'", SQL_NTS) copies the SQL into the statement buffer. - SQLNumParams(hstmt, ...) calls PGAPI_NumParams(). - PGAPI_NumParams() calls SC_scanQueryAndCountParams(). - SC_scanQueryAndCountParams() saw the leading quote, CC_get_escape() returned 0, and the E'' prefix check read ENCODE_PTR(encstr)[-1]. ASan before the fix reported: - heap-buffer-overflow READ of size 1 - statement.c:1125 in SC_scanQueryAndCountParams - address located 1 byte before the buffer allocated by make_string() from PGAPI_Prepare() The patch guards the E'' prefix check in the three scanner paths so the previous byte is read only when the current scanner position is not at the beginning of the SQL string. This preserves E'' handling and avoids changing normal literal parsing. Verification in WSL: - Built psqlodbc with -fsanitize=address,undefined - Reproduced the ASan failure before the fix with exe/leading-literal-numparams-test - Rebuilt after the fix and confirmed the same test prints nparams=0 without ASan errors - Ran the project harness: ./runsuite leading-literal-numparams --inputdir=. -> ok 1