Buffer overflow errors after upcp

SunHunter

• August 09, 2017 03:29

Hi, I've got a number of PHP scripts which run using cron and these have all started failing since the /usr/local/cpanel/scripts/upcp script finished running this morning. I've had a stable environment on a dedicated server for a number of years but suddenly after the script finished running at 3.37 AM this morning all my PHP cron jobs are failing with the following error:
*** buffer overflow detected ***: /usr/local/bin/php terminated ======= Backtrace: ========= /lib64/libc.so.6(__fortify_fail+0x37)[0x7ffb2773f7f7] /lib64/libc.so.6(+0x1006e0)[0x7ffb2773d6e0] /lib64/libc.so.6(+0xffb39)[0x7ffb2773cb39] /lib64/libc.so.6(_IO_default_xsputn+0xc9)[0x7ffb276b14a9] /lib64/libc.so.6(_IO_vfprintf+0x64f)[0x7ffb2768148f] /lib64/libc.so.6(__vsprintf_chk+0x9d)[0x7ffb2773cbdd] /lib64/libc.so.6(__sprintf_chk+0x7f)[0x7ffb2773cb1f] /usr/local/bin/php[0x403328] /usr/local/bin/php[0x402169] /usr/local/bin/php[0x40171f] /lib64/libc.so.6(__libc_start_main+0xfd)[0x7ffb2765bd1d] /usr/local/bin/php[0x4011e9]
I'm really not sure how to go about fixing this, or it's a known problem, but just wanted to report it.

• 

  SunHunter

  • August 09, 2017 08:50

  As an aside, although PHP scripts run via cron seem to be failing with the above message, the website on the same server seems to be working normally. If I invoke the same 'cron' scripts from within a browser they work without error, but from the command line they cause a buffer overflow (this wasn't happening before the last upcp).

  0
• 

  SunHunter

  • August 09, 2017 11:33

  Just trying to troubleshoot this and even if the script is empty, I still get a buffer overflow e.g. if I have a PHP script file does_nothing.php
  
  and run this
  php does_nothing.php
  I still get a buffer overflow, so it looks like something has been disturbed by upcp to do with the command line environment. I've just found out if I run /usr/local/bin/php -ea_php 56 does_nothing.php I do not get a buffer overflow (which is odd, as if I run /usr/local/bin/php -v the version number is already 5.6.31 so wouldn't have thought I'd need to use a ea_php version override!)

  0
• 

  rpvw

  • August 09, 2017 11:51

  The last EA4 update that would seem to have coincided with the onset of your problem are detailed in EasyApache 4 Update - August 8, 2017

  0
• 

  bidouilleur

  • August 09, 2017 15:13

  Have the same issue with 1 account running on PHP 56, all was ok till midnight server time .. it spits out every time the cron runs .. is this a problem cpanel side or does this imply some code has to be modified our side ... ?? *** buffer overflow detected ***: /usr/bin/php terminated ======= Backtrace: ========= /lib64/libc.so.6(__fortify_fail+0x37)[0x7f2c2bc257f7] /lib64/libc.so.6(+0x1006e0)[0x7f2c2bc236e0] /lib64/libc.so.6(+0xffb39)[0x7f2c2bc22b39] /lib64/libc.so.6(_IO_default_xsputn+0xc9)[0x7f2c2bb974a9] /lib64/libc.so.6(_IO_vfprintf+0x64f)[0x7f2c2bb6748f] /lib64/libc.so.6(__vsprintf_chk+0x9d)[0x7f2c2bc22bdd] /lib64/libc.so.6(__sprintf_chk+0x7f)[0x7f2c2bc22b1f] /usr/bin/php[0x403328] /usr/bin/php[0x402169] /usr/bin/php[0x40171f] /lib64/libc.so.6(__libc_start_main+0xfd)[0x7f2c2bb41d1d] /usr/bin/php[0x4011e9] ======= Memory map: ======== 00400000-00404000 r-xp 00000000 08:02 3067576 /usr/bin/php 00604000-00605000 rw-p 00004000 08:02 3067576 /usr/bin/php 01578000-01599000 rw-p 00000000 00:00 0 [heap] 7f2c2b903000-7f2c2b919000 r-xp 00000000 08:02 1753109 /lib64/libgcc_s-4.4.7-20120601.so.1 7f2c2b919000-7f2c2bb18000 ---p 00016000 08:02 1753109 /lib64/libgcc_s-4.4.7-20120601.so.1 7f2c2bb18000-7f2c2bb19000 rw-p 00015000 08:02 1753109 /lib64/libgcc_s-4.4.7-20120601.so.1 7f2c2bb23000-7f2c2bcad000 r-xp 00000000 08:02 1753151 /lib64/libc-2.12.so 7f2c2bcad000-7f2c2bead000 ---p 0018a000 08:02 1753151 /lib64/libc-2.12.so 7f2c2bead000-7f2c2beb1000 r--p 0018a000 08:02 1753151 /lib64/libc-2.12.so 7f2c2beb1000-7f2c2beb3000 rw-p 0018e000 08:02 1753151 /lib64/libc-2.12.so 7f2c2beb3000-7f2c2beb7000 rw-p 00000000 00:00 0 7f2c2bebb000-7f2c2beda000 r-xp 00000000 08:02 3017086 /usr/lib64/libyaml-0.so.2.0.4 7f2c2beda000-7f2c2c0d9000 ---p 0001f000 08:02 3017086 /usr/lib64/libyaml-0.so.2.0.4 7f2c2c0d9000-7f2c2c0da000 rw-p 0001e000 08:02 3017086 /usr/lib64/libyaml-0.so.2.0.4 7f2c2c0e3000-7f2c2c103000 r-xp 00000000 08:02 1753093 /lib64/ld-2.12.so 7f2c2c303000-7f2c2c304000 r--p 00020000 08:02 1753093 /lib64/ld-2.12.so 7f2c2c304000-7f2c2c305000 rw-p 00021000 08:02 1753093 /lib64/ld-2.12.so 7f2c2c305000-7f2c2c306000 rw-p 00000000 00:00 0 7f2c2c308000-7f2c2c30e000 rw-p 00000000 00:00 0 7ffc24d0d000-7ffc24d22000 rw-p 00000000 00:00 0 [stack] 7ffc24dbb000-7ffc24dbc000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

  0
• 

  cPanelMichael

  • August 09, 2017 16:16

  Hello, Internal case EA-6669 is open to address an issue where long .htaccess directives can cause PHP scripts called via

  0
• 

  JacobPerkins

  • August 09, 2017 21:47

  Hi, The fixes for this have been published and is now live.

  0

Please sign in to leave a comment.