Subject: [postgresql-interfaces/psqlodbc] PR #151: bug causing out-of-bounds memory access in AddUpdated when updating cached row status

From: "0xYashwanth (@0xYashwanth)" <[email-masked]>
Date: Sun, 04 Jan 2026 16:57:18 +0000

**bug causing out-of-bounds memory access in `AddUpdated()` when updating cached row status.**

In the `else if (upd_idx >= 0)` branch at line 2691, the code updates `res->updated_keyset[upd_idx].status` but then incorrectly accesses `res->added_tuples + num_fields * upd_add_idx` to clear cached data.

When a row's status in the `updated_keyset` array is modified, the corresponding cached tuple data must be invalidated. 
The invariant is: **for any index `i`, the tuple cache entry is stored at `base_array + num_fields * i`**. Since we're modifying `updated_keyset[upd_idx]`, the corresponding tuple cache is at `updated_tuples + num_fields * upd_idx`. 
Using the wrong base array (`added_tuples`) or wrong index (`upd_add_idx = -1`) violates this and produces undefined behavior.

## Fix
```c
tuple = res->updated_tuples + num_fields * upd_idx;
```

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Sun, 04 Jan 2026 19:11:13 +0000

is there a way to test this ?

---

From: "jarvis24young (@jarvis24young)" <[email-masked]>
Date: Tue, 28 Apr 2026 08:58:02 +0000

@davecramer is there already testcases when u merged this?

---

From: "jarvis24young (@jarvis24young)" <[email-masked]>
Date: Wed, 29 Apr 2026 01:15:26 +0000

@0xYashwanth  Without such a reproducer, I agree the code fix is correct, but it is hard to
  assess the practical exploitability or whether a black-box regression test can
  be added.