php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #75795 Interned strings buffer overflow cause crash in Rouncdube webmail
Submitted: 2018-01-10 16:10 UTC Modified: 2018-01-24 14:36 UTC
From: post at minhost dot no Assigned:
Status: Closed Package: opcache
PHP Version: 7.1.13 OS: CentOS 7.4
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: post at minhost dot no
New email:
PHP Version: OS:

 

 [2018-01-10 16:10 UTC] post at minhost dot no
Description:
------------
(This bug is related to bug #75579 wich was fixed in PHP 7.1.13.)

First some info about my setup: I am running Apache 2.4.29, PHP-FPM 7.1.13 with Opcache both in memory and with file cache on disk. Here is my Opcache .ini settings:

opcache.memory_consumption=32768
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=1000000
opcache.revalidate_freq=0
opcache.validate_timestamps=1
opcache.fast_shutdown=1
opcache.enable_cli=0
opcache.validate_permission=1
opcache.validate_root=1
opcache.use_cwd=1
opcache.revalidate_path=1
opcache.enable_file_override=1
opcache.file_cache=/var/www/tmp/.opcache
opcache.file_cache_only=0
opcache.max_wasted_percentage=10

After upgrade from PHP 7.1.11 to PHP 7.1.13 the previous bug #75579 seems fixed except for Roundcube webmail wich still crash. All other PHP scripts seems to work correct.

What happens is when interned_strings_buffer is empty and Roundcube webmail have not been visited before interned_strings_buffer became empty, so it is not in Opcache already, then it will crash when you visit the log in page to Roundcube webmail. At the same time, all other PHP scripts works correct except for Roundcube webmail. When it crash it will display this in a browser:

Service Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Additionally, a 503 Service Unavailable error was encountered while trying to use an ErrorDocument to handle the request.

And in Apche error log it will display this:

[Wed Jan 10 11:07:10.167008 2018] [proxy_fcgi:error] [pid 26262:tid 139668105803520] (104)Connection reset by peer: [client 176.74.214.18:52064] AH01075: Error dispatching request to :

If you reload PHP-FPM and visit Roundcube webmail log in page before interned_strings_buffer become empty, then it will work without crashing, and it will continue to work even when interned_strings_buffer become empty later on. So the crash will only happen when nobody have visited Roundcube webmail before interned_strings_buffer became empty, then it will crash on a visit to the page and continue to not work until next time PHP-FPM is reloaded.

Here is how to quickly reproduce the bug. Configure Opcache with file_cache enabled and set interned_strings_buffer to 0:

opcache.interned_strings_buffer=0
opcache.file_cache=/var/www/tmp/.opcache
opcache.file_cache_only=0

Then install latest Roundcube webmail version 1.3.3 from roundcube.net and visit Roundcube login page, it will then crash as described above. If you then remove the .ini setting opcache.file_cache, it will work again without crashing.

If your are patient enough, you could also set opcache.interned_strings_buffer very low to for example 1, and then visit other PHP pages on the server until the interned buffer strings is all used and empty, and then you can visit Roundcube webmail login page, and it will crash, but alle other PHP pages, except Roundcube, will continue to work. But remember to not visit Roundcube before interned_strings_buffer is empty.

Please use this to figure out wich PHP scripts/code in Roundcube webmail that is triggering this bug in interned_strings_buffer. Please let me know if you need more information about my setup.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-01-24 14:34 UTC] post at minhost dot no
It seems the bug was not in PHP. The problem described started after we 4 of january updated to new linux-firmware and microcode_ctl from CentOS/RedHat:

linux-firmware security update (2018-01-03):
https://access.redhat.com/errata/RHSA-2018:0014

microcode_ctl security update (2018-01-03):
https://access.redhat.com/errata/RHSA-2018:0012

Then at 2018-01-16 RedHat reverted the linux-firmware and microcode_ctl update to the last known good version dated before 03 January 2018:

linux-firmware security update (2018-01-16):
https://access.redhat.com/errata/RHSA-2018:0094

microcode_ctl security update (2018-01-16):
https://access.redhat.com/errata/RHSA-2018:0093

After I updated my systems to the reverted linux-firmware and microcode_ctl update from of 2018-01-16, then the bug disappeared! This is really crazy. I am not able to reproduce the bug after I updated to the reverted updates from RedHat.

Because of this, I am closing this bug report.
 [2018-01-24 14:36 UTC] post at minhost dot no
-Status: Open +Status: Closed
 [2018-01-24 14:36 UTC] post at minhost dot no
Closing this bug report because it seems fixed after updating to reverted linux-firmware and microcode_ctl update from of 2018-01-16
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 27 11:01:30 2024 UTC