| Bug #42502 | huge memory leak possible with timezone functions | ||
|---|---|---|---|
| Submitted: | 31 Jan 19:00 | Modified: | 13 Apr 21:22 |
| Reporter: | Shane Bester | ||
| Status: | Closed | ||
| Category: | Server: General | Severity: | S1 (Critical) |
| Version: | 4.1.24, 5.0.74, 5.1.30,6.0.9 | OS: | Any |
| Assigned to: | Staale Smedseng | Target Version: | 5.0+ |
| Tags: | timezone, convert_tz, DoS, memory leak | ||
| Triage: | Triaged: D1 (Critical) | ||
[31 Jan 19:24]
Valeriy Kravchuk
Thank you for the problem report.
[31 Jan 19:48]
Valeriy Kravchuk
This way one may force a leak of up to global max_allowed_packet per each call.
[17 Mar 17:04]
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/69468 2839 Staale Smedseng 2009-03-17 Bug #42502 huge memory leak possible with timezone functions Unknown timezone specifications are properly rejected by the server, but are copied into tz_storage before rejection, and hence is retained until end of server life. With sufficiently large bogus timezone specs, it is easy to exhaust system memory. Allocation of memory for a copy of the timezone name is delayed until after verification of validity, at the cost of a memcpy of the timezone info (currently 88 bytes).
[19 Mar 11:28]
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/69743 2781 Staale Smedseng 2009-03-19 Bug #42502 huge memory leak possible with timezone functions Unknown timezone specifications are properly rejected by the server, but are copied into tz_storage before rejection, and hence is retained until end of server life. With sufficiently large bogus timezone specs, it is easy to exhaust system memory. Allocation of memory for a copy of the timezone name is delayed until after verification of validity, at the cost of a memcpy of the timezone info. This only happens once, future lookups will hit the cached structure.
[27 Mar 15:31]
Bugs System
Pushed into 5.0.80 (revid:joro@sun.com-20090327142516-55gumdxj39z6eijj) (version source revid:leonard@mysql.com-20090324072904-7w2lxdxzw8hx1rnm) (merge vers: 5.0.80) (pib:6)
[27 Mar 15:56]
Bugs System
Pushed into 5.1.34 (revid:joro@sun.com-20090327143448-wuuuycetc562ty6o) (version source revid:horst@mysql.com-20090319113025-89p0piatdyuuy9hi) (merge vers: 5.1.34) (pib:6)
[30 Mar 4:29]
Paul DuBois
Noted in 5.0.80, 5.1.34 changelogs. Passing an unknown time zone specification to CONVERT_TZ() resulted in a memory leak. Setting report to NDI pending push into 6.0.x.
[13 Apr 11:22]
Bugs System
Pushed into 6.0.11-alpha (revid:alik@sun.com-20090413084402-snnrocwzktcl88ny) (version source revid:horst@mysql.com-20090319112816-dz4j1eq9a316rqa6) (merge vers: 6.0.11-alpha) (pib:6)
[13 Apr 21:22]
Paul DuBois
Noted in 6.0.11 changelog.
[9 May 18:43]
Bugs System
Pushed into 5.1.34-ndb-6.2.18 (revid:jonas@mysql.com-20090508185236-p9b3as7qyauybefl) (version source revid:jonas@mysql.com-20090508185236-p9b3as7qyauybefl) (merge vers: 5.1.34-ndb-6.2.18) (pib:6)
[9 May 19:40]
Bugs System
Pushed into 5.1.34-ndb-6.3.25 (revid:jonas@mysql.com-20090509063138-1u3q3v09wnn2txyt) (version source revid:jonas@mysql.com-20090509063138-1u3q3v09wnn2txyt) (merge vers: 5.1.34-ndb-6.3.25) (pib:6)
[9 May 20:37]
Bugs System
Pushed into 5.1.34-ndb-7.0.6 (revid:jonas@mysql.com-20090509154927-im9a7g846c6u1hzc) (version source revid:jonas@mysql.com-20090509154927-im9a7g846c6u1hzc) (merge vers: 5.1.34-ndb-7.0.6) (pib:6)
Description: there is a memory leak with functions that use timezone info. How to repeat: #watch memory usage increase with each statement: set global max_allowed_packet=100*1024*1024; \r select convert_tz('','',repeat('a',104857600)); select convert_tz('','',repeat('a',104857600)); select convert_tz('','',repeat('a',104857600)); select convert_tz('','',repeat('a',104857600)); select convert_tz('','',repeat('a',104857600)); select convert_tz('','',repeat('a',104857600));