USN-3109-1: MySQL vulnerabilities partially applies to MariaDB too

I am a member of the Ubuntu development team since August. I haven't uploaded anything to Ubuntu yet and if I recall correctly I am not able to upload security updates myself, but still need a sponsor for these.

The 5.5 series update for 14.04 is now available.

Please use git-buildpackage to fetch and build from the ubuntu-14.04 branch at http://anonscm.debian.org/cgit/pkg-mysql/mariadb-5.5.git/log/?h=ubuntu-14.04

The repository uses pristine-tar, so there is no need to separately download the sources. You can just check the signature/SHA1SUM directly from the git-buildpackage generated tarball.

Test build currently running at https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb/+builds?build_text=&build_state=all

10.0 series updates for 16.04 and 16.10 are now available.

Please use git-buildpackage to fetch and build from the ubuntu-16.04 and ubuntu-16.10 branches at http://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git

The repository uses pristine-tar, so there is no need to separately download the sources. You can just check the signature/SHA1SUM directly from the git-buildpackage generated tarball.

Test build are currently running at https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.0/+builds?build_text=&build_state=all

MariaDB 10.0.28 has already been uploaded to Debian unstable for some while. There was no regressions.

Otto, now that you're a developer you should be able to upload mariadb packages to the current devel release all you want.

You're correct that updates for previous releases should go through the security sponsoring process.

Thanks

2016-11-02 0:02 GMT+02:00 Seth Arnold <email address hidden>:
> Otto, now that you're a developer you should be able to upload mariadb
> packages to the current devel release all you want.

Can you please remind me where to find the documentation about how to
trigger or control the automatic Debian sid ->Ubuntu devel sync
process? At the moment there is no delta, so the sync should be
automatic, but for future use. Thanks!

The syncpackage manpage.

Otto, can you confirm that you intended to drop mdev-9479-oqgraph-boost.patch in the Yakkety upload? There's no mention in the changelog so I'd like to be sure before I sponsor the upload.

All three uploads are building in the ubuntu-security-proposed ppa:

  https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa

I won't publish them until I've heard back regarding the mdev-9479-oqgraph-boost.patch patch that I asked about in comment #7.

The yakkety armhf build failed due to failing tests:

  https://launchpadlibrarian.net/292078830/buildlog_ubuntu-yakkety-armhf.mariadb-10.0_10.0.28-0ubuntu0.16.10.1_BUILDING.txt.gz

Is that something that you can look into so that we can have armhf updates, Otto?

The armhf failure did not surface during the Debian upload. Can you trigger a rebuild?

I have enabled the armhf now for our test repo at https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.0 and will try to reproduce this issue now.

The retried build also failed:

https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/11139691/+files/buildlog_ubuntu-yakkety-armhf.mariadb-10.0_10.0.28-0ubuntu0.16.10.1_BUILDING.txt.gz

Thanks

Otto, can you confirm that you intended to drop mdev-9479-oqgraph-boost.patch in the Yakkety upload?

Thanks

Yes, mdev-9479-oqgraph-boost.patch was applied upstream and thus dropped in this release.

We are still working on the armhf build failure. It is repeatable at https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.0/+builds?build_text=&build_state=all

Please stay on hold with the upload for a few more days until I publish an improved revision, thanks.

Thanks Otto

Please go ahead and upload all the other versions apart from Yakkety.

It will take some time to fix the armhf build issue. I will notify when done and then the Yakkety version can be uploaded.

The armhf build issue for Yakkety is now fixed and test builds at https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.0/+builds?build_text=&build_state=all pass.

Please use git-buildpackage to fetch and build from the ubuntu-16.04 and ubuntu-16.10 branches at http://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git

The new Yakkety upload built successfully in the security ppa. I'll be sponsoring all three uploads shortly. Big thanks, once again, Otto!

This bug was fixed in the package mariadb-10.0 - 10.0.28-0ubuntu0.16.04.1

---------------
mariadb-10.0 (10.0.28-0ubuntu0.16.04.1) xenial-security; urgency=low

  * SECURITY UPDATE: New upstream release 10.0.28. Includes fixes for the
    following security vulnerabilities (LP: #1638125):
    - CVE-2016-8283
    - CVE-2016-7440
    - CVE-2016-6663
    - CVE-2016-5629
    - CVE-2016-5626
    - CVE-2016-5624
    - CVE-2016-5616
    - CVE-2016-5584
    - CVE-2016-3492
  * Update old changelog entries to include new CVE identifiers

 -- Otto Kekäläinen <email address hidden> Mon, 31 Oct 2016 22:34:22 +0200

This bug was fixed in the package mariadb-5.5 - 5.5.53-1ubuntu0.14.04.1

---------------
mariadb-5.5 (5.5.53-1ubuntu0.14.04.1) trusty-security; urgency=low

  * SECURITY UPDATE: New upstream release 5.5.53. Includes fixes for the
    following security vulnerabilities (LP: #1638125):
    - CVE-2016-7440
    - CVE-2016-5584
  * Update previous changelog entries to contain new CVE identifiers

 -- Otto Kekäläinen <email address hidden> Mon, 31 Oct 2016 23:48:54 +0200

This bug was fixed in the package mariadb-10.0 - 10.0.28-0ubuntu0.16.10.1

---------------
mariadb-10.0 (10.0.28-0ubuntu0.16.10.1) yakkety-security; urgency=high

  [ Otto Kekäläinen ]
  * SECURITY UPDATE: New upstream release 10.0.28. Includes fixes for the
    following security vulnerabilities (LP: #1638125):
    - CVE-2016-8283
    - CVE-2016-7440
    - CVE-2016-6663
    - CVE-2016-5629
    - CVE-2016-5626
    - CVE-2016-5624
    - CVE-2016-5616
    - CVE-2016-5584
    - CVE-2016-3492
  * Previous release 10.0.27 included included fixes for
    the following security vulnerabilities:
    - CVE-2016-6662
    - CVE-2016-5630
    - CVE-2016-5612
  * Previous release 10.0.26 included included fixes for
    the following security vulnerabilities:
    - CVE-2016-3615
    - CVE-2016-3521
    - CVE-2016-3477
  * Add Ubuntu Developers as maintainer in d/control

  [ Vicențiu Ciorbaru ]
  * Fix connect.upd test in armhf
  * Fix mroonga/storage.index_read_multiple_double test in armhf

 -- Otto Kekäläinen <email address hidden> Thu, 01 Dec 2016 13:36:08 +0200

10.0.28-0ubuntu0.16.10.1 was applied last night as an unattended update to my server and wiped out /var/lib/mysql...

Log started: 2016-12-08 03:37:45
Preconfiguring packages ...
(Reading database ... ^M(Reading database ... 5%^M(Reading database ... 10%^M(Reading database ... 15%^M(Reading database ... 20%^M(Reading database ... 25%^M(Reading database ... 30%^M(Reading database ... 35%^M(Reading database ... 40%^M(Reading database ... 45%^M(Reading database ... 50%^M(Reading database ... 55%^M(Reading database ... 60%^M(Reading database ... 65%^M(Reading database ... 70%^M(Reading database ... 75%^M(Reading database ... 80%^M(Reading database ... 85%^M(Reading database ... 90%^M(Reading database ... 95%^M(Reading database ... 100%^M(Reading database ... 172311 files and directories currently installed.)
Preparing to unpack .../mariadb-common_10.0.28-0ubuntu0.16.04.1_all.deb ...
Unpacking mariadb-common (10.0.28-0ubuntu0.16.04.1) over (10.0.27-0ubuntu0.16.04.1) ...
Preparing to unpack .../mariadb-client-core-10.0_10.0.28-0ubuntu0.16.04.1_amd64.deb ...
Unpacking mariadb-client-core-10.0 (10.0.28-0ubuntu0.16.04.1) over (10.0.27-0ubuntu0.16.04.1) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up mariadb-common (10.0.28-0ubuntu0.16.04.1) ...
(Reading database ... ^M(Reading database ... 5%^M(Reading database ... 10%^M(Reading database ... 15%^M(Reading database ... 20%^M(Reading database ... 25%^M(Reading database ... 30%^M(Reading database ... 35%^M(Reading database ... 40%^M(Reading database ... 45%^M(Reading database ... 50%^M(Reading database ... 55%^M(Reading database ... 60%^M(Reading database ... 65%^M(Reading database ... 70%^M(Reading database ... 75%^M(Reading database ... 80%^M(Reading database ... 85%^M(Reading database ... 90%^M(Reading database ... 95%^M(Reading database ... 100%^M(Reading database ... 172311 files and directories currently installed.)
Preparing to unpack .../mariadb-server-10.0_10.0.28-0ubuntu0.16.04.1_amd64.deb ...
/var/lib/mysql: found previous version 10.0
Unpacking mariadb-server-10.0 (10.0.28-0ubuntu0.16.04.1) over (10.0.27-0ubuntu0.16.04.1) ...
Preparing to unpack .../mariadb-client-10.0_10.0.28-0ubuntu0.16.04.1_amd64.deb ...
Unpacking mariadb-client-10.0 (10.0.28-0ubuntu0.16.04.1) over (10.0.27-0ubuntu0.16.04.1) ...
Preparing to unpack .../mariadb-server-core-10.0_10.0.28-0ubuntu0.16.04.1_amd64.deb ...
Unpacking mariadb-server-core-10.0 (10.0.28-0ubuntu0.16.04.1) over (10.0.27-0ubuntu0.16.04.1) ...
Preparing to unpack .../mariadb-server_10.0.28-0ubuntu0.16.04.1_all.deb ...
Unpacking mariadb-server (10.0.28-0ubuntu0.16.04.1) over (10.0.27-0ubuntu0.16.04.1) ...
Processing triggers for systemd (229-4ubuntu12) ...
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up mariadb-client-core-10.0 (10.0.28-0ubuntu0.16.04.1) ...
Setting up mariadb-client-10.0 (10.0.28-0ubuntu0.16.04.1) ...
Setting up mariadb-server-core-10.0 (10.0.28-0ubuntu0.16.04.1) ...
Setting up mariadb-server-10.0 (10.0.28-0ubuntu0.16.04.1) ...
this is very strange! see /tmp/mysql-symlink-restore-forbvv/README...
Setting up mariadb-server (10.0.28-0ubuntu0.16.04.1) ...
Log ended: 20...

Regarding ironstorm's note in #21, we didn't realize our /var/lib/mysql folder was moved to /tmp/mysql-symlink-restore-forbvv/.

Apparently a previous upgrade of mysql-5.7 left /var/lib/mysql-upgrade/ in place with a DATADIR symlink to 'mysql-5.7'. This confused mariadb-server-10.0.postinst [1] and triggered the "# this should never even happen, but just in case..." block. Neither ironstorm or I noticed that our /var/lib/mysql folder had been moved into /tmp, so we thought it had been lost.

Glad to not have data loss, but pretty spooked. /tmp does not seem like a very good place for this since it could be automatically wiped.

[1] https://fossies.org/linux/mariadb/debian/dist/Debian/mariadb-server-10.0.postinst

i.e. If the server had been configured with Unattended-Upgrade::Automatic-Reboot "true" and a kernel update came down at the same time, the DB moved to /tmp would have been wiped as part of the reboot process.

ironstorm or RJ Ryan:

Thank you for the note. Please could you file a separate bug with exact steps to reproduce your situation please? Feel free to subscribe me to that bug, and please link that bug from here.