This bug was fixed in the package php7.0 - 7.0.15-0ubuntu0.16.10.4
---------------
php7.0 (7.0.15-0ubuntu0.16.10.4) yakkety-security; urgency=medium
* SECURITY REGRESSION: large mysql requests broken (LP: #1668017)
- debian/patches/fix_74021.patch: fix fetch_array with more than
MEDIUMBLOB in ext/mysqlnd/mysqlnd_wireprotocol.c, added tests to
ext/mysqli/tests/bug73800.phpt, ext/mysqli/tests/bug74021.phpt.
-- Marc Deslauriers <marc.deslauri...@ubuntu.com> Wed, 01 Mar 2017
10:50:27 -0500
** Changed in: php7.0 (Ubuntu Yakkety)
Status: Fix Committed => Fix Released
** Changed in: php7.0 (Ubuntu Xenial)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1668017
Title:
Large mysql requests broken after security update, null character
inserted close to 16MB boundary
Status in php7.0 package in Ubuntu:
Fix Released
Status in php7.0 source package in Xenial:
Fix Released
Status in php7.0 source package in Yakkety:
Fix Released
Bug description:
SRU team: as this is a SRU and security regression, I'm hopeful we can
bypass the 7-day waiting period, presuming @jbruijn or I can test the
version from -proposed first.
[Impact]
* The prior SRU of 7.0.15 included an upstream regression to MySQL
support with large blobs.
* The fix has not yet been published in an upstream release, but is
planned for 7.0.17.
[Test Case]
- Ubuntu 16.04
- MariaDB Server (not tested on mysql, but I expect similar results)
- php 7.0 (7.0.15)
- phpMyAdmin
Configuration:
MariaDB: max_allowed_packet = 128M
php: post_max_size and upload_max_filesize raised to 128M
Import some SQL data, for instance: https://we.tl/vb37KISpUU.
This will build you a MyISAM table with 4 columns, 3x varchar(1) and 1
longblob. The table will have one big blob in it, with 32Mbyte worth of 0x20
(space)
Downloading the binary through phpMyAdmin on 7.0.15 will produce a
file with a null-character inserted at (for my setup) 0xFFFFF6, the
rest of the file is as expected.
[Regression Potential]
* This upload includes the upstream fix, as well as testcases for the
same. As this is a fix to an existing regression, I do not believe
there is any chance of regression and it should be caught by the test
sutie.
---
I'm running a web application serving rather big binary blobs from a
MariaDB table. After the unattended update (7.0.8-0ubuntu0.16.04.3 to
7.0.15-0ubuntu0.16.04.2), the application would routinely break while
trying to fetch a >16Mbyte row from the database server.
Requests resulting in a row under 16Mbyte are processed normally,
anything above it would return columns in the wrong order, and right
around 0xFFFFF2 a null-character (0x00) is inserted into the stream
(when the resulting file is compared to one served with the version
used previously)
Rolling back to 7.0.4-7ubuntu2 immediately fixed the issue. I'm pretty
sure the problem was introduced somewhere between 7.0.8 and 7.0.15,
but I cant find anything relevant in the changelog for those versions.
Please let me know what I can do to assist!
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/php7.0/+bug/1668017/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
