|
2020-02-23
| ||
| 17:38 | • Fixed ticket [f50af3e8]: OOB memory access on a table rename plus 5 other changes (artifact: 929fcf1d user: drh) | |
| 17:34 | Fix a problem with ALTER TABLE for views that have a nested FROM clause. Ticket [f50af3e8a565776b]. (check-in: c431b3fd user: drh tags: trunk) | |
| 16:16 | • Ticket [f50af3e8] OOB memory access on a table rename status still Open with 6 other changes (artifact: 569133e7 user: drh) | |
| 16:09 | • New ticket [f50af3e8]. (artifact: 8fb06da9 user: drh) | |
| Ticket Hash: | f50af3e8a565776b1dd3248dfa2d4a87d60e4153 | |||
| Title: | OOB memory access on a table rename | |||
| Status: | Fixed | Type: | Code_Defect | |
| Severity: | Important | Priority: | Low | |
| Subsystem: | Unknown | Resolution: | Fixed | |
| Last Modified: | 2020-02-23 17:38:04 | |||
| Version Found In: | 3.31.1 | |||
| User Comments: | ||||
|
drh added on 2020-02-23 16:09:56:
The ALTER TABLE statement in the following SQL causes an out-of-bounds memory access: CREATE TABLE t1(x); CREATE VIEW t2 AS SELECT 1 FROM t1, (t1 AS a0, t1); ALTER TABLE t1 RENAME TO t3; This problem was discovered and reported by sakura(@eternalsakura13) of Alpha Team, Qihoo 360 drh added on 2020-02-23 16:16:40: The OOB memory access occurs inside the renameTokenCheckAll() procedure, which is a debugging procedure that only exists for debugging builds. It is unclear whether or not this problem exists in release builds. drh added on 2020-02-23 17:38:04: The test case shown above is indeed harmless for release builds. However, Sakura provides another more complex test case (not shown here) that does cause an OOB memory access on release builds due to the two-size lookaside memory allocator added in version 3.31.0. It is the same problem in both cases, and is fixed by check-in [c431b3fd8fd0f6a6]. | ||||