php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79509 Segfault on wsdl tmp files from different architecture
Submitted: 2020-04-22 20:18 UTC Modified: 2020-04-23 07:50 UTC
From: brunni at netestate dot de Assigned: cmb (profile)
Status: Duplicate Package: SOAP related
PHP Version: 7.2.30 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: brunni at netestate dot de
New email:
PHP Version: OS:

 

 [2020-04-22 20:18 UTC] brunni at netestate dot de
Description:
------------
I just spent 6.5 hours tracing a segmentation fault in PHP. The SOAP module in my new 64bit PHP was trying to read an architecture dependent binary file named /tmp/wsdl-www-00... apparently generated weeks earlier by my old 32bit PHP - and crashed over and over. Once I deleted all /tmp/wsdl-* files, all was fine.

I don't think it's a good idea not to use architecture information like compile time when generating those temporary files. I'm also not sure it's a good idea to let them lie around in /tmp and reuse them weeks later.




Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-04-22 22:58 UTC] brunni at netestate dot de
Two more things:

-Is the serialization involved supposed to be secure? If yes you have a bigger problem.

-As the file names seem to be predictable: Is file ownership checked before using a file? If no I can apparently crash other users PHP interpreters.
 [2020-04-23 07:50 UTC] cmb@php.net
-Status: Open +Status: Duplicate -Assigned To: +Assigned To: cmb
 [2020-04-23 07:50 UTC] cmb@php.net
Duplicate of bug #70951.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Apr 24 05:01:30 2024 UTC