Bug 435391 - mysql does not calculate thread stack size correctly for RHEL5
mysql does not calculate thread stack size correctly for RHEL5
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mysql (Show other bugs)
ppc64 Linux
medium Severity medium
: rc
: ---
Assigned To: Tom Lane
Depends On:
  Show dependency treegraph
Reported: 2008-02-28 18:23 EST by Tom Lane
Modified: 2013-07-02 23:17 EDT (History)
2 users (show)

See Also:
Fixed In Version: RHSA-2008-0364
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 11:24:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tom Lane 2008-02-28 18:23:41 EST
Description of problem:
mysql estimates available stack space for a thread as the requested stack size less a constant (16KB
in our current builds).  However, it turns out that glibc actually allocates the requested stack size
less a "guard area" that by default is the same size as a hardware page.  The existing constant value
implicitly includes enough room for a typical guard area of 4KB.  But RHEL5 changes the hardware
page size to 64KB on ppc64 (maybe ppc also, I'm not certain).  On this platform mysql does not allow
enough stack headroom and therefore will crash on overly-complex queries, rather than returning
a suitable error message as intended.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Try to run the package's regression tests
Actual results:
execution_constants test, which intentionally exercises mysql's stack overflow defenses,
reports a crash.

Expected results:
Tests should all pass.

Additional info:
This could easily be seen as a security bug, since a malicious query could cause a transient DOS
for all users of a mysql database.  Since there are lots of possible denials of service available to
an attacker with the ability to issue arbitrary SQL, I don't think it's worth treating as a security
exercise.  But it seems sufficiently important to propose as an exception for RHEL 5.2, especially
since we are already turning mysql in 5.2.

The correct fix is to account for the guard area while setting the requested stack space.  
This problem has already been encountered on the Fedora build machines (which run RHEL5 kernels)
and the proposed patch has been tested there.
Comment 1 Tom Lane 2008-02-28 18:27:46 EST
See also bug #435337.  However, unless I can convince Jakub that the behavior is a glibc bug, we're going 
to need to work around it in mysql.
Comment 2 Tom Lane 2008-03-20 11:40:57 EDT
BTW, the reason this problem wasn't seen long ago is that our build machines still run RHEL4, which uses 
smaller page sizes.  The problem became apparent only after the Fedora build machines were updated to 
RHEL5 kernels.  I understand that sometime soon the brew machines will be updated to RHEL5 kernels, 
which will mean that mysql will fail to be buildable at all unless it gets this patch.  Shipping a package 
that we know we can no longer rebuild from source doesn't seem like a good policy...
Comment 9 errata-xmlrpc 2008-05-21 11:24:06 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.