The call stack is generated on my windows machine. This is using an older version of PHP. Here's the output on my Linux machine:

# ./php -v
PHP 8.0.0-dev (cli) (built: Feb  5 2019 11:40:32) ( NTS DEBUG )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v4.0.0-dev, Copyright (c) Zend Technologies
# ./php write_access_violation.php

AddressSanitizer:DEADLYSIGNAL
=================================================================
==2871==ERROR: AddressSanitizer: SEGV on unknown address 0x0000deadbeef (pc 0x7fd17b5eefeb bp 0x61e000001b00 sp 0x7fff2e933210 T0)
==2871==The signal is caused by a READ memory access.
    #0 0x7fd17b5eefea  (/usr/lib/x86_64-linux-gnu/libxml2.so.2+0x32fea)
    #1 0xa17fe6  (/root/Documents/Fuzzing/PHP/install/bin/php+0xa17fe6)
    #2 0xa002c0  (/root/Documents/Fuzzing/PHP/install/bin/php+0xa002c0)
    #3 0x190845a  (/root/Documents/Fuzzing/PHP/install/bin/php+0x190845a)
    #4 0x173e856  (/root/Documents/Fuzzing/PHP/install/bin/php+0x173e856)
    #5 0x173f59d  (/root/Documents/Fuzzing/PHP/install/bin/php+0x173f59d)
    #6 0x15a7a3f  (/root/Documents/Fuzzing/PHP/install/bin/php+0x15a7a3f)
    #7 0x12fc3e4  (/root/Documents/Fuzzing/PHP/install/bin/php+0x12fc3e4)
    #8 0x1ad1954  (/root/Documents/Fuzzing/PHP/install/bin/php+0x1ad1954)
    #9 0x1ace7b9  (/root/Documents/Fuzzing/PHP/install/bin/php+0x1ace7b9)
    #10 0x7fd17b3e409a  (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
    #11 0x448789  (/root/Documents/Fuzzing/PHP/install/bin/php+0x448789)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/usr/lib/x86_64-linux-gnu/libxml2.so.2+0x32fea) 
==2871==ABORTING

>  Any hexadecimal value translates semi directly to a value used in memory.

Could you explain what you mean by that? Any example?

>  Any hexadecimal value translates semi directly to a value used in memory.

> Could you explain what you mean by that? Any example?

As far as I've found out so far any numeric value filled in the encoding property will be written to the EDX register in the CPU. Using the added comments in the test script we can make the following script as well:

<?php // shortest version
$imp = new DOMImplementation;
$dom = $imp->createDocument("", "");
$dom->encoding = -16+0x41424344;

In this case the value -16+0x41424344 will translate to 0x41424344 in the EDX register (on my windows machine). On my linux machine I had to do +18+0x41424344 to get the same result.

What I mean by "Any hexadecimal value translates semi directly to a value used in memory" is that you need to calculate the right value to get where you want to be. So as i said in the example above I use -16+0x41424344, which ends up as 41424344 in the EDX register.

In this case the process crashes on an access violation at that address. This indicates a write access violation since an attacker can control the write address and value.

I hope I made myself more clear. If you need any further information please let me know.

The problem seems to be in this code:

   342 		str = zval_get_string(newval);
   343 	
   344 		handler = xmlFindCharEncodingHandler(Z_STRVAL_P(newval));

It converts newval to string, but then for some reason uses un-converted value to call xmlFindCharEncodingHandler. That's definitely wrong. 

Not sure it's a security issue, unless there's a plausible scenario where DOM encoding is being set from non-string values. I can't see any so far.

If the value filled in the encoding is used in a call or jmp statement an attacker may fill in a memory value to a part in memory that he controls. This can lead to an arbitrary code execution.

So far I have not been able to proof this possible though in this specific situation.

> If the value filled in the encoding is used in a call or jmp statement an attacker may fill in a memory value to a part in memory that he controls. This can lead to an arbitrary code execution.

If the attacker can run the code to set the encoding, he is already executing arbitrary code. The only scenario where this can be a security issue is if the encoding can be set to a non-string value by a legitimate script not written by the attacker. But I can't see any plausible scenario how it can happen.

@stas: Any decision on how to classify this? The patch is very simple:

diff --git a/ext/dom/document.c b/ext/dom/document.c
index c9e1802f78..11ef4aa818 100644
--- a/ext/dom/document.c
+++ b/ext/dom/document.c
@@ -341,7 +341,7 @@ int dom_document_encoding_write(dom_object *obj, zval *newval)
 
        str = zval_get_string(newval);
 
-       handler = xmlFindCharEncodingHandler(Z_STRVAL_P(newval));
+       handler = xmlFindCharEncodingHandler(ZSTR_VAL(str));
 
     if (handler != NULL) {
                xmlCharEncCloseFunc(handler);

> But I can't see any plausible scenario how it can happen.

Me neither.

Anyhow, we need a decision whether this is a security issue or
not.  If it isn't, it's still a bug, and the fix is trivial.  If
it is, we should address it as soon as possible.

I'd commit it to 7.2 out of abundance of caution, but I don't think it needs CVE really because I don't see any plausible scenario how it could be exploited.