| Bug #38823 | Invalid memory access when a SP statement does wildcard expansion | ||
|---|---|---|---|
| Submitted: | 15 Aug 2008 15:02 | Modified: | 10 Nov 2008 18:23 |
| Reporter: | Philip Stoev | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server | Severity: | S1 (Critical) |
| Version: | 5.1-bzr, 6.0-bzr | OS: | Any |
| Assigned to: | Davi Arnaut | CPU Architecture: | Any |
[15 Aug 2008 15:33]
MySQL Verification Team
Thank you for the bug report. Also repeatable in older versions like 6.0.2.
[15 Aug 2008 19:46]
MySQL Verification Team
output of valgrind shows numerous invalid memory accesses
Attachment: bug38823_valgrind_errors.txt (text/plain), 34.45 KiB.
[1 Oct 2008 21:11]
Davi Arnaut
A simpler test case: DELIMITER |; CREATE PROCEDURE C () BEGIN SELECT * FROM t1; END| --error ER_NO_SUCH_TABLE CALL C| CREATE TABLE t1 (a INTEGER)| CALL C| ALTER TABLE t1 ADD b INTEGER; CALL C|
[2 Oct 2008 12:58]
Davi Arnaut
Workaround: explicitly indicate the columns to retrieve instead of using the asterisk wildcard character (*).
[14 Oct 2008 14:05]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/56182 2705 Davi Arnaut 2008-10-14 Bug#38823: Invalid memory access when a SP statement does wildcard expansion The problem is that field names constructed due to wild-card expansion done inside a stored procedure could point to freed memory if the expansion was performed after the first call to the stored procedure. The problem was solved by patch for Bug#38691. The solution was to allocate the database, table and field names in the in the statement memory instead of table memory.
[14 Oct 2008 14:13]
Davi Arnaut
Queued to 5.0-bugteam
[14 Oct 2008 17:59]
Paul DuBois
The fix for Bug#38691 also fixed Bug#38823, so it is fixed in the same versions. Noted in 5.0.72, 5.1.29 changelogs. Column names constructed due to wild-card expansion done inside a stored procedure could point to freed memory if the expansion was performed after the first call to the stored procedure.
[24 Oct 2008 8:42]
Bugs System
Pushed into 5.0.72 (revid:davi.arnaut@sun.com-20081014140436-e23dnjl426eln3z7) (version source revid:davi.arnaut@sun.com-20081014140436-e23dnjl426eln3z7) (pib:5)
[24 Oct 2008 20:16]
Paul DuBois
Setting to NDI pending push into 6.0.x.
[10 Nov 2008 10:53]
Bugs System
Pushed into 6.0.8-alpha (revid:davi.arnaut@sun.com-20081014140436-e23dnjl426eln3z7) (version source revid:davi.arnaut@sun.com-20081016021316-p7etwjgausmhe08d) (pib:5)
[10 Nov 2008 11:37]
Bugs System
Pushed into 5.1.30 (revid:davi.arnaut@sun.com-20081014140436-e23dnjl426eln3z7) (version source revid:davi.arnaut@sun.com-20081016015056-tii2mzf5tirlcshs) (pib:5)
[10 Nov 2008 18:23]
Paul DuBois
Note in 6.0.8 changelog.
[11 Nov 2008 16:27]
Paul DuBois
6.0.9 changelog, not 6.0.8.
[19 Jan 2009 11:27]
Bugs System
Pushed into 5.1.31-ndb-6.2.17 (revid:tomas.ulin@sun.com-20090119095303-uwwvxiibtr38djii) (version source revid:tomas.ulin@sun.com-20090108105244-8opp3i85jw0uj5ib) (merge vers: 5.1.31-ndb-6.2.17) (pib:6)
[19 Jan 2009 13:05]
Bugs System
Pushed into 5.1.31-ndb-6.3.21 (revid:tomas.ulin@sun.com-20090119104956-guxz190n2kh31fxl) (version source revid:tomas.ulin@sun.com-20090119104956-guxz190n2kh31fxl) (merge vers: 5.1.31-ndb-6.3.21) (pib:6)
[19 Jan 2009 16:11]
Bugs System
Pushed into 5.1.31-ndb-6.4.1 (revid:tomas.ulin@sun.com-20090119144033-4aylstx5czzz88i5) (version source revid:tomas.ulin@sun.com-20090119144033-4aylstx5czzz88i5) (merge vers: 5.1.31-ndb-6.4.1) (pib:6)
Description: If a procedure is defined that references a table and then a trigger is installed on that table, calling the procedure results in an error like: ERROR 42S22: Unknown column 'test:ю h4z▐▐▐▐).pk' in 'field list' The error message contains garbage and unrelated parts of server's memory (so this is a potential privacy/security hole). How to repeat: --disable_abort_on_error DELIMITER |; CREATE TABLE t1 ( pk INTEGER AUTO_INCREMENT, int_nokey INTEGER NOT NULL, int_key INTEGER NOT NULL, PRIMARY KEY (pk), KEY (int_key) )| CREATE PROCEDURE C () BEGIN SELECT * FROM t2; END| CALL C| CREATE TABLE IF NOT EXISTS t2 PARTITION BY HASH ( `pk` ) PARTITIONS 8 SELECT `pk` , `int_key` FROM t1| CALL C| CREATE TRIGGER i BEFORE INSERT ON t2 FOR EACH ROW BEGIN END| CALL C| Suggested fix: It is very unfortunate that this memory corruption was caught only because it was made visible by an error message. Extra assertions would have helped catch it closer to the source.