Per the release notes on the respective links... The following versions include fixes to CVE vulnerabilities: 10.1.18 [1]: Fixes for the following security vulnerabilities: CVE-2016-5616 CVE-2016-5624 CVE-2016-5626 CVE-2016-3492 CVE-2016-5629 CVE-2016-8283 CVE-2016-6663 This vulnerability was discovered by Dawid Golunski. 10.0.28 [2]: Fixes for the following security vulnerabilities: CVE-2016-5616 CVE-2016-5624 CVE-2016-5626 CVE-2016-3492 CVE-2016-5629 CVE-2016-8283 CVE-2016-7440 CVE-2016-5584 CVE-2016-6663 This vulnerability was discovered by Dawid Golunski. 5.5.53 [3]: Fixes for the following security vulnerabilities: CVE-2016-7440 CVE-2016-5584 [1] https://mariadb.com/kb/en/mariadb/mariadb-10118-release-notes/ [2] https://mariadb.com/kb/en/mariadb/mariadb-10028-release-notes/ [3] https://mariadb.com/kb/en/mariadb/mariadb-5553-release-notes/
Here's some more background, this looks pretty bad: http://legalhackers.com/advisories/MySQL-Maria-Percona-PrivEscRace-CVE-2016-6663-5616-Exploit.html The fixed versions (10.1.18, 10.0.28) are already in the tree. Can we start stabiliziing
Arches, please test and mark stable. The test suite should pass following the official instructions. Local timeouts may be expected on resource starved machines. (each test thread can spawn up to 4 server instances) Target keywords: =dev-db/mariadb-10.0.28 alpha amd64 arm hppa ia64 ppc ppc64 sparc x86 # Official test instructions: # USE='embedded extraengine perl server openssl static-libs' \ # FEATURES='test userpriv -usersandbox' \ # ebuild mariadb-10.0.28.ebuild \ # digest clean package # Parallel testing is enabled, auto will try to detect number of cores # You may set this by hand. # The default maximum is 8 unless MTR_MAX_PARALLEL is increased export MTR_PARALLEL="${MTR_PARALLEL:-auto}"
Stable for HPPA PPC64.
amd64 stable
x86 stable
arm stable
Stable on alpha.
CVE's assigned to bug 597538 which will be addressed in the same GLSA.
sparc stable
ia64 stable
ppc stable. Maintainer(s), please cleanup.
Cleanup complete
This issue was resolved and addressed in GLSA 201701-01 at https://security.gentoo.org/glsa/201701-01 by GLSA coordinator Thomas Deutschmann (whissi).