Clang on Windows: undefined behavior?

[cmb69]

Description

I came back to working with Clang on Windows, and did a minimal build with ASan and UBSan support (using the VS 2022 supplied clang 18.1.8):

configure --with-toolset=clang --disable-all --enable-cli --enable-sanitizer --enable-debug-pack

Now the following happens:

$ x64\Release_TS\php -v
TSRM\TSRM.c:265:7: runtime error: call to function sapi_globals_ctor through pointer to incorrect function type 'void (*)(void *)'
C:\php-sdk\phpdev\vs17\x64\php-src\main\SAPI.c:53: note: sapi_globals_ctor defined here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior TSRM\TSRM.c:265:7
Zend/zend_ini_parser.y:377:4: runtime error: call to function php_ini_parser_cb through pointer to incorrect function type 'void (*)(struct _zval_struct *, struct _zval_struct *, struct _zval_struct *, int, void *)'
C:\php-sdk\phpdev\vs17\x64\php-src\main\php_ini.c:184: note: php_ini_parser_cb defined here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior Zend/zend_ini_parser.y:377:4
PHP 8.5.0-dev (cli) (built: Jan 13 2025 13:48:08) (ZTS clang version 18.1.8  x64)
Copyright (c) The PHP Group
Zend Engine v4.5.0-dev, Copyright (c) Zend Technologies
TSRM\TSRM.c:560:8: runtime error: call to function basic_globals_dtor through pointer to incorrect function type 'void (*)(void *)'
C:\php-sdk\phpdev\vs17\x64\php-src\ext\standard\basic_functions.c:248: note: basic_globals_dtor defined here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior TSRM\TSRM.c:560:8
TSRM\TSRM.c:170:5: runtime error: call to function file_globals_dtor through pointer to incorrect function type 'void (*)(void *)'
C:\php-sdk\phpdev\vs17\x64\php-src\ext\standard\file.c:138: note: file_globals_dtor defined here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior TSRM\TSRM.c:170:5

I've stumbled upon this earlier, and back then considered these bogus diagnostics. I'm not sure any longer, though, but still suprised that this hasn't been caught so far (or are there some UBSan suppressions in place?) Maybe someone can clarify whether this is a proper diagnostic, or some false positive.

Note that applying

 Zend/zend_ini.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Zend/zend_ini.h b/Zend/zend_ini.h
index 1939d7b89e..3a72deb12d 100644
--- a/Zend/zend_ini.h
+++ b/Zend/zend_ini.h
@@ -234,7 +234,7 @@ END_EXTERN_C()
 #define ZEND_INI_STAGE_IN_REQUEST   (ZEND_INI_STAGE_ACTIVATE|ZEND_INI_STAGE_DEACTIVATE|ZEND_INI_STAGE_RUNTIME|ZEND_INI_STAGE_HTACCESS)
 
 /* INI parsing engine */
-typedef void (*zend_ini_parser_cb_t)(zval *arg1, zval *arg2, zval *arg3, int callback_type, void *arg);
+typedef void (*zend_ini_parser_cb_t)(zval *arg1, zval *arg2, zval *arg3, int callback_type, HashTable *arg);
 BEGIN_EXTERN_C()
 ZEND_API zend_result zend_parse_ini_file(zend_file_handle *fh, bool unbuffered_errors, int scanner_mode, zend_ini_parser_cb_t ini_parser_cb, void *arg);
 ZEND_API zend_result zend_parse_ini_string(const char *str, bool unbuffered_errors, int scanner_mode, zend_ini_parser_cb_t ini_parser_cb, void *arg);

fixes the php_ini_parser_cb() warning.

PHP Version

master (but likely irrelevant)

Operating System

Windows

[arnaud-lb]

We can find all such cases with -Wcast-function-type-strict. I think they are not harmful, but this could break some security hardening features such as CFI.

Currently --enable-undefined-sanitizer disables these checks explicitly because fixing these would require a lot of changes, but ideally we should avoid introducing new cases.

[cmb69]

Currently --enable-undefined-sanitizer disables these checks explicitly because fixing these would require a lot of changes, […]

Ah, thank you! (Additionally passing -fno-sanitize=function indeed suppresses the warnings for me.)

I think they are not harmful, but this could break some security hardening features such as CFI.

Yeah, not nice.

[nielsdos]

I looked into this a few weeks ago, and the work that needs to be done is huge indeed. It took a while to get the test runner working without errors, but even then many warnings popped up. It goes as deep as the rc_dtor_func even...