Bug 435391

Summary: mysql does not calculate thread stack size correctly for RHEL5
Product: Red Hat Enterprise Linux 5 Reporter: Tom Lane <tgl>
Component: mysqlAssignee: Tom Lane <tgl>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5.2CC: byte, hhorak
Target Milestone: rc   
Target Release: ---   
Hardware: ppc64   
OS: Linux   
URL: http://bugs.mysql.com/bug.php?id=35019
Whiteboard:
Fixed In Version: RHSA-2008-0364 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-21 15:24:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tom Lane 2008-02-28 23:23:41 UTC
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):
mysql-5.0.45-6

How reproducible:
100%

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 23:27:46 UTC
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 15:40:57 UTC
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 15:24:06 UTC
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.

http://rhn.redhat.com/errata/RHSA-2008-0364.html