Markus Koschany <apo@debian.org> writes:
> I also tried to fix CVE-2015-8834 for Wheezy by backporting
> changeset/32387 but the database upgrade failed, at least I could not
> log back into the admin backend again. Did you notice a similar issue
> for Jessie?
I just had a look at this issue. Not sure I understand why the database
upgrade failed, however I think I see bigger problem.
Part of the patch changes the db_version:
-$wp_db_version = 30133;
+$wp_db_version = 30135;
It puts in a new migration after:
if ( $wp_current_db_version < 29630 )
upgrade_400();
The exact addition is:
if ( $wp_current_db_version < 30135 )
upgrade_415();
It looks like this upgrade_415() checks all stored comments, and deletes
entries where the comment length is too long. It would appear that mysql
doesn't enforce the maximum length when writing the comment, and somehow
this causes a security issue when we later read it back (not sure I
really understand this).
In Wheezy the db version is:
$wp_db_version = 24448;
In wheezy the latest migration is:
if ( $wp_current_db_version < 22422 )
upgrade_350();
This means a number of db upgrades are not in the wheezy version that
are assumed to exist by the patch. We can't just apply the patch as is
by itself, because this will upgrade the wp_db_version to 30135, and
will mean upgrades from Jessie to newer versions will not work as we
have skipped the required migrations.
It is possible we could upgrade the version to 24449 and use 24448 to
trigger the migration, however not really comfortable doing this in case
that number is already used upstream somewhere.
Any comments?
--
Brian May <bam@debian.org>