Xenforo: https://xenforo.com/community/threads/mariadb-10-3-26-1-breaks-php-7-2.187331/
WHMCS: https://help.whmcs.com/m/troubleshooting/l/1325182-troubleshooting-a-critical-error-could-not-connect-to-the-database-error
Stackoverflow: https://stackoverflow.com/questions/64677836/sqlstatehy000-general-error-1835-malformed-communication-packet-on-laravel
cPanel: https://support.cpanel.net/hc/en-us/articles/360056803454-After-MariaDB-update-PHP-website-has-database-connection-error-MySQL-query-error-Malformed-communication-packet

It is probably we start strictly check prepared statements attributes, there is probably an error in the code, could you provide something reproducable. Or at least sequence of the commands it perform.

Oleksandr,

We have been able to reproduce it with the following snippet (thanks to WHMCS development for providing it):

<?php

​

ini_set('display_errors', 'on');

​

$databaseName = 'MyDatabase';

$host = 'localhost';

$databaseUser = 'myuser';

$databasePassword = 'password';

​

$pdo = new PDO(

    "mysql:dbname={$databaseName};host={$host}",

    $databaseUser,

    $databasePassword

);

​

$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

​

$test = $pdo->prepare("set names 'utf8' collate 'utf8_unicode_ci'")->execute();

​

var_dump($test);

and it returns the following error:

Fatal error: Uncaught PDOException: SQLSTATE[HY000]: General error: 1835 Malformed communication packet in /home/v80whmcssupport/public_html/test.php:26 Stack trace: #0 /home/v80whmcssupport/public_html/test.php(26): PDOStatement->execute() #1 {main} thrown in /home/v80whmcssupport/public_html/test.php on line 26

The system was using

• MariaDB 10.3.26
• mysqlnd 5.0.12-dev

stack overflow has upvoted claims on PDO::ATTR_EMULATE_PREPARES true works around the issue.

The issue isn't exclusive to PHP.

Also seeing it with JDBC on MariaDB 10.5.7.

[11:58:55] [Server thread/WARN]: java.sql.SQLException: Malformed communication packet
[11:58:55] [Server thread/WARN]: at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:965)

The problem with this solution:
[PDO::ATTR_EMULATE_PREPARES => true]
is that it's changing integers to strings in responses. This causes strict conditionals === to fail due to mismatched types.

AlexWebLab thanks for the additional information. Btw I wasn't suggesting it was a solution, only that it helped pinpoint the suspicion that sanja already had.

Intelli can I assume the MariaDB connector J is unaffected? And for clarification which JDBC version?

It looks like some libraries send a byte which mean we will send parameters types even if there is no parameters for the statement at all. So our check takes it as a garbage in the packet.

Could reproduce on CentOS 7 using PHP7.2 and MariaDB 10.4.16 (happened after cronjob updated mariadb)

This was a bug in mysqlnd as in PHP 7.2: https://github.com/php/php-src/blob/PHP-7.2/ext/mysqlnd/mysqlnd_ps_codec.c#L938
Fixed in PHP 7.3: https://github.com/php/php-src/blob/PHP-7.3/ext/mysqlnd/mysqlnd_ps_codec.c#L965
by the commit https://github.com/php/php-src/commit/05a884f6393b1a19f103c2b358e736b20c0f7d46

Old code generated invalid "execute" packets, they were violating both our (https://mariadb.com/kb/en/com_stmt_execute/) and MySQL (https://dev.mysql.com/doc/internals/en/com-stmt-execute.html) description of the protocol.

Latest MariaDB releases have stricter packet validation as a security measure and these broken packets are now rejected.

Your best option would be to use PHP 7.3+ that does not violate the protocol. Although we're currently discussing whether to relax the packet validation to allow these invalid packets as a special exception.

hi i use php 5.6 and have the same issue, i would need to re code my whole site to use php7 (as i use mysqlquery), so please release a patch to solve the issue
thanks mark

There will be soon a new release which relax this check.

perfect thank you

Hello.
I have the same problem as Mark.
Php 5.6 not working.
I need to recode all my plataform to update to o newer php version.
Please release a fix as soon as possible.
Thanks

Whats time to fix in new release??

days

is there anything we can do for a temp solution until the release?

After many workarounds i tried today this the solutions i got

1- upgrade to php 7.3 or 7.4
(many websites will be down after php upgrades )

2- downgrade to minor version ( mariadb 10.4.16 to 10.4.15)

yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel    

Thanks, RedVirus.

The second solution worked for me (for now)!

@Daniel Soares you are welcome
dont forget to lock auto update for MariaDB

@redvirus
How lock auto update for MariaDB?

@Red Grey
you can edit /etc/yum.conf with nano /etc/yum

and exclude specific page from being updated
put at the end

exclude=<package.Name>

example for mariadb

exclude=maria*

this for centos & redhat servers
what is your server OS ?

@RedVirus, CentOS. I'll try that.
Do I need to restart something for this to work?
Thanks

@Daniel Soares

no you dont need to restart anything but for make sure just restart your database server

systemctl restart mariadb
or
service mysqld restart

@Daniel Black The software experiencing issues is utilizing mysql-connector-java 5.1.49 (Released Apr 28, 2020).

I'm using PHP 7.2.x client. Thus the following servers are suddenly BROKEN for me:

10.1.48, 10.2.35, 10.3.26, 10.4.16, 10.5.7

One workaround is to downgrade to one version prior.

Unfortunately, upgrading PHP is not an option for me.

After some further testing, it seems the issue in Java is being triggered by setting the fetch size.

This can either be caused by adding "defaultFetchSize=" to the connecting string, or by running it on a statement.

For example:

statement.setFetchSize(10);

I can confirm @Sergei Golubchik statement that by backporting PHP 7.3 mysqlnd code outlined to PHP 7.1 and 7.2 fixes the errors for Xenforo and Wordpress at least https://community.centminmod.com/threads/mariadb-10-5-7-10-4-16-10-3-26-10-2-35-and-10-1-48-now-available.20632/#post-86953 allowing PHP 7.2 to work again

Same Problem with PHP 7.1 PDO::ATTR_EMULATE_PREPARES causes strict conditionals === to fail due to mismatched types.

Since this has been fixed in 10.2.36, 10.3.27 etc - is there an ETA for those being published to the /10.2/, /10.3/ yum repositories? I see the specific version repo is published: http://yum.mariadb.org/10.3.27/centos7-amd64/rpms/ - however, the generic 10.3 repo does not.

Since this has been fixed in 10.2.36, 10.3.27 etc - is there an ETA for those being published to Dockerhub mariadb official image ?

MariaDB official images are not maintained by MariaDB, you need to ask the maintainer of the images.
https://github.com/docker-library/mariadb

For all those watching patiently, there have been packages released https://mariadb.org/mariadb-10-5-8-10-4-17-10-3-27-and-10-2-36-now-available/

jliebert with the mariadb release, the docker library official images picked up the release and pushed their release