Bug #38823 Invalid memory access when a SP statement does wildcard expansion

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.

Thank you for the bug report. Also repeatable in older versions like 6.0.2.

output of valgrind shows numerous invalid memory accesses

Attachment: bug38823_valgrind_errors.txt (text/plain), 34.45 KiB.

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|

Workaround: explicitly indicate the columns to retrieve instead of using the asterisk wildcard character (*).

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.

Queued to 5.0-bugteam

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.

Pushed into 5.0.72  (revid:davi.arnaut@sun.com-20081014140436-e23dnjl426eln3z7) (version source revid:davi.arnaut@sun.com-20081014140436-e23dnjl426eln3z7) (pib:5)

Setting to NDI pending push into 6.0.x.

Pushed into 6.0.8-alpha  (revid:davi.arnaut@sun.com-20081014140436-e23dnjl426eln3z7) (version source revid:davi.arnaut@sun.com-20081016021316-p7etwjgausmhe08d) (pib:5)

Pushed into 5.1.30  (revid:davi.arnaut@sun.com-20081014140436-e23dnjl426eln3z7) (version source revid:davi.arnaut@sun.com-20081016015056-tii2mzf5tirlcshs) (pib:5)

Note in 6.0.8 changelog.

6.0.9 changelog, not 6.0.8.

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)

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)

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)