Problem with POST's #10
Assignees
Comments
|
So, what was wrong? I'm expiriencing same problem. NGINX Unit is installed from latest source from this repo (0.4 so far) and no proxies are used |
|
Yes, I'm using latest master (and I checked this file too). This what I've got in log with as you can see data was recieved but result was empty PS I use: |
|
I added logging to that part I'm not sure how to set length correctly but now I see in log. So that patch works but everything else is still like in my previous post. |
|
@vladkras it seems the previous attempt to fix isn't complete, please try the following patch: --- a/src/nxt_http_request.c Fri Jan 12 16:37:42 2018 +0300
+++ b/src/nxt_http_request.c Fri Jan 12 16:39:18 2018 +0300
@@ -221,6 +221,7 @@ nxt_http_app_request(nxt_task_t *task, v
if (r->body != NULL) {
ar->r.body.buf = r->body;
ar->r.body.preread_size = r->content_length_n;
+ ar->r.header.parsed_content_length = r->content_length_n;
}
ar->r.body.done = 1; |
|
@VBart yes, this line helps I'll try to send more data and files too. |
nginx-hg-mirror
pushed a commit
that referenced
this issue
May 18, 2023
There are a couple of reports on GitHub about issues accessing Python ASGI based applications over IPv6. A request over IPv6 would result in an error like 2023/05/13 17:49:12 [alert] 47202#47202 [unit] #10: Python failed to create 'client' pair 2023/05/13 17:49:12 [alert] 47202#47202 [unit] Python failed to call 'loop.call_soon' ValueError: invalid literal for int() with base 10: 'db8:1:1:1ee7:dead:beef:cafe' The above error was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib64/python3.11/asyncio/base_events.py", line 765, in call_soon handle = self._call_soon(callback, args, context) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.11/asyncio/base_events.py", line 781, in _call_soon handle = events.Handle(callback, args, self, context) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ SystemError: <class 'asyncio.events.Handle'> returned a result with an exception set This issue occurred in the nxt_py_asgi_create_ip_address() function where it tries to create an IP address / port number pair. It does this by looking for the first ':' in the address and taking everything after it as the port number. Like in the above error message, if we tried to access the server @ 2001:db8:1:1:1ee7:dead:beef:cafe, then we'd end up with the port number as 'db8:1:1:1ee7:dead:beef:cafe'. There are two issues with this 1) The IP address and port number are already flowed through separately. 2) Even if (1) wasn't true, it would still be broken for IPv6 as we'd expect to a get an address literal like [2001:db8:1:1:1ee7:dead:beef:cafe]:8080, however there was no code to handle the []'s. The fix is to simply not try looking for a port number. We pass a port number into this function to use in the case where we don't find a port number, we never will... A further cleanup would be to flow through the server port number when creating the 'server pair' PyTuple, rather than just using the hard coded 80. Closes: <#793> Closes: <#874> Reviewed-by: Alejandro Colomar <[email protected]> Signed-off-by: Andrew Clayton <[email protected]>
ac000
added a commit
to ac000/unit
that referenced
this issue
Nov 8, 2023
If ruby/rack tried to send an empty header, e.g
app = Proc.new do |env|
["200", {
"Content-Type" => "text/plain",
"X-Empty-Header" => nil,
}, ["Hello World\n"]]
end
run app
you would get an error like
2023/10/20 11:24:56 [error] 24829#24829 [unit] nginx#10: Ruby: Wrong header entry 'value' from application
2023/10/20 11:24:56 [error] 24829#24829 [unit] nginx#10: Ruby: Failed to run ruby script
Empty headers are a thing, so we need to allow the ruby type T_NIL
(along with T_STRING) as a valid header value.
This factors out the setting of value & value_end into a macro as what
these get set to now depends on if we have a T_NIL or a T_STRING and
this prevents an increase in duplicated code.
Signed-off-by: Andrew Clayton <[email protected]>
ac000
added a commit
to ac000/unit
that referenced
this issue
Nov 8, 2023
If ruby/rack tried to send an empty header, e.g
app = Proc.new do |env|
["200", {
"Content-Type" => "text/plain",
"X-Empty-Header" => nil,
}, ["Hello World\n"]]
end
run app
you would get an error like
2023/10/20 11:24:56 [error] 24829#24829 [unit] nginx#10: Ruby: Wrong header entry 'value' from application
2023/10/20 11:24:56 [error] 24829#24829 [unit] nginx#10: Ruby: Failed to run ruby script
Empty headers are a thing, so we need to allow the ruby type T_NIL
(along with T_STRING) as a valid header value.
This factors out the setting of value & value_end into a macro as what
these get set to now depends on if we have a T_NIL or a T_STRING and
this prevents an increase in duplicated code.
Signed-off-by: Andrew Clayton <[email protected]>
andrey-zelenkov
added a commit
to andrey-zelenkov/unit
that referenced
this issue
Jan 31, 2024
Can be reproduced by test/test_rewrite.py::test_rewrite_njs
with enabled UndefinedBehaviorSanitizer:
src/nxt_http_js.c:169:52: runtime error: applying zero offset to null pointer
#0 0x10255b044 in nxt_http_js_ext_get_args nxt_http_js.c:169
nginx#1 0x102598ad0 in njs_value_property njs_value.c:1175
nginx#2 0x10259c2c8 in njs_vm_object_prop njs_vm.c:1398
nginx#3 0x102559d74 in nxt_js_call nxt_js.c:445
nginx#4 0x1023c0da0 in nxt_tstr_query nxt_tstr.c:276
nginx#5 0x102516ec4 in nxt_http_rewrite nxt_http_rewrite.c:56
nginx#6 0x1024fd86c in nxt_http_request_action nxt_http_request.c:565
nginx#7 0x1024d71b0 in nxt_h1p_request_body_read nxt_h1proto.c:998
nginx#8 0x1023f5c48 in nxt_event_engine_start nxt_event_engine.c:542
nginx#9 0x1023e2838 in nxt_thread_trampoline nxt_thread.c:126
nginx#10 0x18133e030 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x7030)
nginx#11 0x181338e38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1e38)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/nxt_http_js.c:169:52
Same fix was introduced in NJS:
http://hg.nginx.org/njs/rev/4fba78789fe4
andrey-zelenkov
added a commit
to andrey-zelenkov/unit
that referenced
this issue
Jan 31, 2024
Can be reproduced by test/test_rewrite.py::test_rewrite_njs
with enabled UndefinedBehaviorSanitizer:
src/nxt_http_js.c:169:52: runtime error: applying zero offset to null pointer
#0 0x10255b044 in nxt_http_js_ext_get_args nxt_http_js.c:169
nginx#1 0x102598ad0 in njs_value_property njs_value.c:1175
nginx#2 0x10259c2c8 in njs_vm_object_prop njs_vm.c:1398
nginx#3 0x102559d74 in nxt_js_call nxt_js.c:445
nginx#4 0x1023c0da0 in nxt_tstr_query nxt_tstr.c:276
nginx#5 0x102516ec4 in nxt_http_rewrite nxt_http_rewrite.c:56
nginx#6 0x1024fd86c in nxt_http_request_action nxt_http_request.c:565
nginx#7 0x1024d71b0 in nxt_h1p_request_body_read nxt_h1proto.c:998
nginx#8 0x1023f5c48 in nxt_event_engine_start nxt_event_engine.c:542
nginx#9 0x1023e2838 in nxt_thread_trampoline nxt_thread.c:126
nginx#10 0x18133e030 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x7030)
nginx#11 0x181338e38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1e38)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/nxt_http_js.c:169:52
Same fix was introduced in NJS:
http://hg.nginx.org/njs/rev/4fba78789fe4
andrey-zelenkov
added a commit
to andrey-zelenkov/unit
that referenced
this issue
Feb 7, 2024
These tests cause router crash when run with AddressSanitizer:
=================================================================
==77196==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000079340 at pc 0x55d56b132d4b bp 0x7f8cc7f346b0 sp 0x7f8cc7f346a0
READ of size 1 at 0x60c000079340 thread T1
#0 0x55d56b132d4a in nxt_openssl_conn_io_shutdown src/nxt_openssl.c:1466
nginx#1 0x55d56b0f6a25 in nxt_h1p_closing src/nxt_h1proto.c:2069
nginx#2 0x55d56b1009a6 in nxt_h1p_shutdown src/nxt_h1proto.c:2038
nginx#3 0x55d56b1014c3 in nxt_h1p_request_close src/nxt_h1proto.c:1718
nginx#4 0x55d56b1045c0 in nxt_http_request_close_handler src/nxt_http_request.c:864
nginx#5 0x55d56b104988 in nxt_http_request_done src/nxt_http_request.c:795
nginx#6 0x55d56b0ba0c3 in nxt_event_engine_start src/nxt_event_engine.c:542
nginx#7 0x55d56b0dcac2 in nxt_router_thread_start src/nxt_router.c:3645
nginx#8 0x55d56b0b421b in nxt_thread_trampoline src/nxt_thread.c:126
nginx#9 0x7f8ccab95ac2 (/lib/x86_64-linux-gnu/libc.so.6+0x94ac2)
nginx#10 0x7f8ccac2784f (/lib/x86_64-linux-gnu/libc.so.6+0x12684f)
andrey-zelenkov
added a commit
to andrey-zelenkov/unit
that referenced
this issue
Feb 9, 2024
Can be reproduced by test/test_rewrite.py::test_rewrite_njs
with enabled UndefinedBehaviorSanitizer:
src/nxt_http_js.c:169:52: runtime error: applying zero offset to null pointer
#0 0x10255b044 in nxt_http_js_ext_get_args nxt_http_js.c:169
nginx#1 0x102598ad0 in njs_value_property njs_value.c:1175
nginx#2 0x10259c2c8 in njs_vm_object_prop njs_vm.c:1398
nginx#3 0x102559d74 in nxt_js_call nxt_js.c:445
nginx#4 0x1023c0da0 in nxt_tstr_query nxt_tstr.c:276
nginx#5 0x102516ec4 in nxt_http_rewrite nxt_http_rewrite.c:56
nginx#6 0x1024fd86c in nxt_http_request_action nxt_http_request.c:565
nginx#7 0x1024d71b0 in nxt_h1p_request_body_read nxt_h1proto.c:998
nginx#8 0x1023f5c48 in nxt_event_engine_start nxt_event_engine.c:542
nginx#9 0x1023e2838 in nxt_thread_trampoline nxt_thread.c:126
nginx#10 0x18133e030 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x7030)
nginx#11 0x181338e38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1e38)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/nxt_http_js.c:169:52
Same fix was introduced in NJS:
<http://hg.nginx.org/njs/rev/4fba78789fe4>
andrey-zelenkov
added a commit
to andrey-zelenkov/unit
that referenced
this issue
Feb 21, 2024
Can be reproduced by test/test_rewrite.py::test_rewrite_njs
with enabled UndefinedBehaviorSanitizer:
src/nxt_http_js.c:169:52: runtime error: applying zero offset to null pointer
#0 0x10255b044 in nxt_http_js_ext_get_args nxt_http_js.c:169
nginx#1 0x102598ad0 in njs_value_property njs_value.c:1175
nginx#2 0x10259c2c8 in njs_vm_object_prop njs_vm.c:1398
nginx#3 0x102559d74 in nxt_js_call nxt_js.c:445
nginx#4 0x1023c0da0 in nxt_tstr_query nxt_tstr.c:276
nginx#5 0x102516ec4 in nxt_http_rewrite nxt_http_rewrite.c:56
nginx#6 0x1024fd86c in nxt_http_request_action nxt_http_request.c:565
nginx#7 0x1024d71b0 in nxt_h1p_request_body_read nxt_h1proto.c:998
nginx#8 0x1023f5c48 in nxt_event_engine_start nxt_event_engine.c:542
nginx#9 0x1023e2838 in nxt_thread_trampoline nxt_thread.c:126
nginx#10 0x18133e030 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x7030)
nginx#11 0x181338e38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1e38)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/nxt_http_js.c:169:52
Same fix was introduced in NJS:
<http://hg.nginx.org/njs/rev/4fba78789fe4>
andrey-zelenkov
added a commit
that referenced
this issue
Feb 21, 2024
These tests cause router crash when run with AddressSanitizer:
=================================================================
==77196==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000079340 at pc 0x55d56b132d4b bp 0x7f8cc7f346b0 sp 0x7f8cc7f346a0
READ of size 1 at 0x60c000079340 thread T1
#0 0x55d56b132d4a in nxt_openssl_conn_io_shutdown src/nxt_openssl.c:1466
#1 0x55d56b0f6a25 in nxt_h1p_closing src/nxt_h1proto.c:2069
#2 0x55d56b1009a6 in nxt_h1p_shutdown src/nxt_h1proto.c:2038
#3 0x55d56b1014c3 in nxt_h1p_request_close src/nxt_h1proto.c:1718
#4 0x55d56b1045c0 in nxt_http_request_close_handler src/nxt_http_request.c:864
#5 0x55d56b104988 in nxt_http_request_done src/nxt_http_request.c:795
#6 0x55d56b0ba0c3 in nxt_event_engine_start src/nxt_event_engine.c:542
#7 0x55d56b0dcac2 in nxt_router_thread_start src/nxt_router.c:3645
#8 0x55d56b0b421b in nxt_thread_trampoline src/nxt_thread.c:126
#9 0x7f8ccab95ac2 (/lib/x86_64-linux-gnu/libc.so.6+0x94ac2)
#10 0x7f8ccac2784f (/lib/x86_64-linux-gnu/libc.so.6+0x12684f)
andrey-zelenkov
added a commit
to andrey-zelenkov/unit
that referenced
this issue
Feb 22, 2024
Can be reproduced by test/test_rewrite.py::test_rewrite_njs
with enabled UndefinedBehaviorSanitizer:
src/nxt_http_js.c:169:52: runtime error: applying zero offset to null pointer
#0 0x10255b044 in nxt_http_js_ext_get_args nxt_http_js.c:169
nginx#1 0x102598ad0 in njs_value_property njs_value.c:1175
nginx#2 0x10259c2c8 in njs_vm_object_prop njs_vm.c:1398
nginx#3 0x102559d74 in nxt_js_call nxt_js.c:445
nginx#4 0x1023c0da0 in nxt_tstr_query nxt_tstr.c:276
nginx#5 0x102516ec4 in nxt_http_rewrite nxt_http_rewrite.c:56
nginx#6 0x1024fd86c in nxt_http_request_action nxt_http_request.c:565
nginx#7 0x1024d71b0 in nxt_h1p_request_body_read nxt_h1proto.c:998
nginx#8 0x1023f5c48 in nxt_event_engine_start nxt_event_engine.c:542
nginx#9 0x1023e2838 in nxt_thread_trampoline nxt_thread.c:126
nginx#10 0x18133e030 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x7030)
nginx#11 0x181338e38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1e38)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/nxt_http_js.c:169:52
Same fix was introduced in NJS:
<http://hg.nginx.org/njs/rev/4fba78789fe4>
Reviewed-by: Andrew Clayton <[email protected]>
andrey-zelenkov
added a commit
to andrey-zelenkov/unit
that referenced
this issue
Feb 22, 2024
Can be reproduced by test/test_rewrite.py::test_rewrite_njs
with enabled UndefinedBehaviorSanitizer:
src/nxt_http_js.c:169:52: runtime error: applying zero offset to null pointer
#0 0x10255b044 in nxt_http_js_ext_get_args nxt_http_js.c:169
nginx#1 0x102598ad0 in njs_value_property njs_value.c:1175
nginx#2 0x10259c2c8 in njs_vm_object_prop njs_vm.c:1398
nginx#3 0x102559d74 in nxt_js_call nxt_js.c:445
nginx#4 0x1023c0da0 in nxt_tstr_query nxt_tstr.c:276
nginx#5 0x102516ec4 in nxt_http_rewrite nxt_http_rewrite.c:56
nginx#6 0x1024fd86c in nxt_http_request_action nxt_http_request.c:565
nginx#7 0x1024d71b0 in nxt_h1p_request_body_read nxt_h1proto.c:998
nginx#8 0x1023f5c48 in nxt_event_engine_start nxt_event_engine.c:542
nginx#9 0x1023e2838 in nxt_thread_trampoline nxt_thread.c:126
nginx#10 0x18133e030 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x7030)
nginx#11 0x181338e38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1e38)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/nxt_http_js.c:169:52
Same fix was introduced in NJS:
<http://hg.nginx.org/njs/rev/4fba78789fe4>
Reviewed-by: Andrew Clayton <[email protected]>
andrey-zelenkov
added a commit
to andrey-zelenkov/unit
that referenced
this issue
Feb 23, 2024
Can be reproduced by test/test_rewrite.py::test_rewrite_njs
with enabled UndefinedBehaviorSanitizer:
src/nxt_http_js.c:169:52: runtime error: applying zero offset to null pointer
#0 0x10255b044 in nxt_http_js_ext_get_args nxt_http_js.c:169
nginx#1 0x102598ad0 in njs_value_property njs_value.c:1175
nginx#2 0x10259c2c8 in njs_vm_object_prop njs_vm.c:1398
nginx#3 0x102559d74 in nxt_js_call nxt_js.c:445
nginx#4 0x1023c0da0 in nxt_tstr_query nxt_tstr.c:276
nginx#5 0x102516ec4 in nxt_http_rewrite nxt_http_rewrite.c:56
nginx#6 0x1024fd86c in nxt_http_request_action nxt_http_request.c:565
nginx#7 0x1024d71b0 in nxt_h1p_request_body_read nxt_h1proto.c:998
nginx#8 0x1023f5c48 in nxt_event_engine_start nxt_event_engine.c:542
nginx#9 0x1023e2838 in nxt_thread_trampoline nxt_thread.c:126
nginx#10 0x18133e030 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x7030)
nginx#11 0x181338e38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1e38)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/nxt_http_js.c:169:52
Same fix was introduced in NJS:
<http://hg.nginx.org/njs/rev/4fba78789fe4>
Reviewed-by: Andrew Clayton <[email protected]>
andrey-zelenkov
added a commit
that referenced
this issue
Feb 27, 2024
These tests cause router crash when run with AddressSanitizer:
=================================================================
==77196==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000079340 at pc 0x55d56b132d4b bp 0x7f8cc7f346b0 sp 0x7f8cc7f346a0
READ of size 1 at 0x60c000079340 thread T1
#0 0x55d56b132d4a in nxt_openssl_conn_io_shutdown src/nxt_openssl.c:1466
#1 0x55d56b0f6a25 in nxt_h1p_closing src/nxt_h1proto.c:2069
#2 0x55d56b1009a6 in nxt_h1p_shutdown src/nxt_h1proto.c:2038
#3 0x55d56b1014c3 in nxt_h1p_request_close src/nxt_h1proto.c:1718
#4 0x55d56b1045c0 in nxt_http_request_close_handler src/nxt_http_request.c:864
#5 0x55d56b104988 in nxt_http_request_done src/nxt_http_request.c:795
#6 0x55d56b0ba0c3 in nxt_event_engine_start src/nxt_event_engine.c:542
#7 0x55d56b0dcac2 in nxt_router_thread_start src/nxt_router.c:3645
#8 0x55d56b0b421b in nxt_thread_trampoline src/nxt_thread.c:126
#9 0x7f8ccab95ac2 (/lib/x86_64-linux-gnu/libc.so.6+0x94ac2)
#10 0x7f8ccac2784f (/lib/x86_64-linux-gnu/libc.so.6+0x12684f)
andrey-zelenkov
added a commit
that referenced
this issue
Mar 11, 2024
Can be reproduced by test/test_rewrite.py::test_rewrite_njs
with enabled UndefinedBehaviorSanitizer:
src/nxt_http_js.c:169:52: runtime error: applying zero offset to null pointer
#0 0x10255b044 in nxt_http_js_ext_get_args nxt_http_js.c:169
#1 0x102598ad0 in njs_value_property njs_value.c:1175
#2 0x10259c2c8 in njs_vm_object_prop njs_vm.c:1398
#3 0x102559d74 in nxt_js_call nxt_js.c:445
#4 0x1023c0da0 in nxt_tstr_query nxt_tstr.c:276
#5 0x102516ec4 in nxt_http_rewrite nxt_http_rewrite.c:56
#6 0x1024fd86c in nxt_http_request_action nxt_http_request.c:565
#7 0x1024d71b0 in nxt_h1p_request_body_read nxt_h1proto.c:998
#8 0x1023f5c48 in nxt_event_engine_start nxt_event_engine.c:542
#9 0x1023e2838 in nxt_thread_trampoline nxt_thread.c:126
#10 0x18133e030 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x7030)
#11 0x181338e38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1e38)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/nxt_http_js.c:169:52
Same fix was introduced in NJS:
<http://hg.nginx.org/njs/rev/4fba78789fe4>
Reviewed-by: Andrew Clayton <[email protected]>
pkillarjun
pushed a commit
to pkillarjun/unit
that referenced
this issue
May 29, 2024
These tests cause router crash when run with AddressSanitizer:
=================================================================
==77196==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000079340 at pc 0x55d56b132d4b bp 0x7f8cc7f346b0 sp 0x7f8cc7f346a0
READ of size 1 at 0x60c000079340 thread T1
#0 0x55d56b132d4a in nxt_openssl_conn_io_shutdown src/nxt_openssl.c:1466
nginx#1 0x55d56b0f6a25 in nxt_h1p_closing src/nxt_h1proto.c:2069
nginx#2 0x55d56b1009a6 in nxt_h1p_shutdown src/nxt_h1proto.c:2038
nginx#3 0x55d56b1014c3 in nxt_h1p_request_close src/nxt_h1proto.c:1718
nginx#4 0x55d56b1045c0 in nxt_http_request_close_handler src/nxt_http_request.c:864
nginx#5 0x55d56b104988 in nxt_http_request_done src/nxt_http_request.c:795
nginx#6 0x55d56b0ba0c3 in nxt_event_engine_start src/nxt_event_engine.c:542
nginx#7 0x55d56b0dcac2 in nxt_router_thread_start src/nxt_router.c:3645
nginx#8 0x55d56b0b421b in nxt_thread_trampoline src/nxt_thread.c:126
nginx#9 0x7f8ccab95ac2 (/lib/x86_64-linux-gnu/libc.so.6+0x94ac2)
nginx#10 0x7f8ccac2784f (/lib/x86_64-linux-gnu/libc.so.6+0x12684f)
pkillarjun
pushed a commit
to pkillarjun/unit
that referenced
this issue
May 29, 2024
Can be reproduced by test/test_rewrite.py::test_rewrite_njs
with enabled UndefinedBehaviorSanitizer:
src/nxt_http_js.c:169:52: runtime error: applying zero offset to null pointer
#0 0x10255b044 in nxt_http_js_ext_get_args nxt_http_js.c:169
nginx#1 0x102598ad0 in njs_value_property njs_value.c:1175
nginx#2 0x10259c2c8 in njs_vm_object_prop njs_vm.c:1398
nginx#3 0x102559d74 in nxt_js_call nxt_js.c:445
nginx#4 0x1023c0da0 in nxt_tstr_query nxt_tstr.c:276
nginx#5 0x102516ec4 in nxt_http_rewrite nxt_http_rewrite.c:56
nginx#6 0x1024fd86c in nxt_http_request_action nxt_http_request.c:565
nginx#7 0x1024d71b0 in nxt_h1p_request_body_read nxt_h1proto.c:998
nginx#8 0x1023f5c48 in nxt_event_engine_start nxt_event_engine.c:542
nginx#9 0x1023e2838 in nxt_thread_trampoline nxt_thread.c:126
nginx#10 0x18133e030 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x7030)
nginx#11 0x181338e38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1e38)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/nxt_http_js.c:169:52
Same fix was introduced in NJS:
<http://hg.nginx.org/njs/rev/4fba78789fe4>
Reviewed-by: Andrew Clayton <[email protected]>
ac000
pushed a commit
to ac000/unit
that referenced
this issue
Jun 25, 2024
This issue was found with oss-fuzz. ==18420==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x55dd798a5797 in nxt_vsprintf unit/src/nxt_sprintf.c:163:31 #1 0x55dd798d5bdb in nxt_conf_vldt_error unit/src/nxt_conf_validation.c:1525:11 #2 0x55dd798dd4cd in nxt_conf_vldt_var unit/src/nxt_conf_validation.c:1560:16 #3 0x55dd798dd4cd in nxt_conf_vldt_if unit/src/nxt_conf_validation.c:1592:16 nginx#4 0x55dd798d55f4 in nxt_conf_vldt_object unit/src/nxt_conf_validation.c:2815:23 nginx#5 0x55dd798d6f84 in nxt_conf_vldt_access_log unit/src/nxt_conf_validation.c:3426:11 nginx#6 0x55dd798d55f4 in nxt_conf_vldt_object unit/src/nxt_conf_validation.c:2815:23 nginx#7 0x55dd798d47bd in nxt_conf_validate unit/src/nxt_conf_validation.c:1421:11 nginx#8 0x55dd79871c82 in LLVMFuzzerTestOneInput unit/fuzzing/nxt_json_fuzz.c:67:5 nginx#9 0x55dd79770620 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13 nginx#10 0x55dd7975adb4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6 nginx#11 0x55dd7976084a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9 nginx#12 0x55dd7978cc42 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 nginx#13 0x7e8192213082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16 nginx#14 0x55dd7975188d in _start Uninitialized value was created by an allocation of 'error.i' in the stack frame #0 0x55dd798dd42b in nxt_conf_vldt_var unit/src/nxt_conf_validation.c:1557:5 #1 0x55dd798dd42b in nxt_conf_vldt_if unit/src/nxt_conf_validation.c:1592:16 The issue was in nxt_tstr_test() where we create an error message with nxt_sprintf(), where this error message is then later used with the '%s' format specifier which expects a nul-terminated string, but by default nxt_sprintf() doesn't nul-terminate, you must use the '%Z' specifier to signify a '\0' at the end of the string. Link: <https://github.com/google/oss-fuzz> Link: <https://oss-fuzz.com/testcase-detail/5545917827055616> Co-developed-by: Zhidao HONG <[email protected]> Signed-off-by: Zhidao HONG <[email protected]> Reviewed-by: Andrew Clayton <[email protected]> Signed-off-by: Arjun <[email protected]> [ Commit message/subject - Andrew ] Signed-off-by: Andrew Clayton <[email protected]>
ac000
pushed a commit
to ac000/unit
that referenced
this issue
Jun 25, 2024
This issue was found with oss-fuzz. ==18420==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x55dd798a5797 in nxt_vsprintf unit/src/nxt_sprintf.c:163:31 #1 0x55dd798d5bdb in nxt_conf_vldt_error unit/src/nxt_conf_validation.c:1525:11 #2 0x55dd798dd4cd in nxt_conf_vldt_var unit/src/nxt_conf_validation.c:1560:16 #3 0x55dd798dd4cd in nxt_conf_vldt_if unit/src/nxt_conf_validation.c:1592:16 nginx#4 0x55dd798d55f4 in nxt_conf_vldt_object unit/src/nxt_conf_validation.c:2815:23 nginx#5 0x55dd798d6f84 in nxt_conf_vldt_access_log unit/src/nxt_conf_validation.c:3426:11 nginx#6 0x55dd798d55f4 in nxt_conf_vldt_object unit/src/nxt_conf_validation.c:2815:23 nginx#7 0x55dd798d47bd in nxt_conf_validate unit/src/nxt_conf_validation.c:1421:11 nginx#8 0x55dd79871c82 in LLVMFuzzerTestOneInput unit/fuzzing/nxt_json_fuzz.c:67:5 nginx#9 0x55dd79770620 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13 nginx#10 0x55dd7975adb4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6 nginx#11 0x55dd7976084a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9 nginx#12 0x55dd7978cc42 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 nginx#13 0x7e8192213082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16 nginx#14 0x55dd7975188d in _start Uninitialized value was created by an allocation of 'error.i' in the stack frame #0 0x55dd798dd42b in nxt_conf_vldt_var unit/src/nxt_conf_validation.c:1557:5 #1 0x55dd798dd42b in nxt_conf_vldt_if unit/src/nxt_conf_validation.c:1592:16 The issue was in nxt_tstr_test() where we create an error message with nxt_sprintf(), where this error message is then later used with the '%s' format specifier which expects a nul-terminated string, but by default nxt_sprintf() doesn't nul-terminate, you must use the '%Z' specifier to signify a '\0' at the end of the string. Link: <https://github.com/google/oss-fuzz> Link: <https://oss-fuzz.com/testcase-detail/5545917827055616> Co-developed-by: Zhidao HONG <[email protected]> Signed-off-by: Zhidao HONG <[email protected]> Reviewed-by: Andrew Clayton <[email protected]> Signed-off-by: Arjun <[email protected]> [ Commit message/subject - Andrew ] Signed-off-by: Andrew Clayton <[email protected]>
ac000
pushed a commit
to ac000/unit
that referenced
this issue
Jun 25, 2024
This issue was found with oss-fuzz. ==18420==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x55dd798a5797 in nxt_vsprintf unit/src/nxt_sprintf.c:163:31 #1 0x55dd798d5bdb in nxt_conf_vldt_error unit/src/nxt_conf_validation.c:1525:11 #2 0x55dd798dd4cd in nxt_conf_vldt_var unit/src/nxt_conf_validation.c:1560:16 #3 0x55dd798dd4cd in nxt_conf_vldt_if unit/src/nxt_conf_validation.c:1592:16 nginx#4 0x55dd798d55f4 in nxt_conf_vldt_object unit/src/nxt_conf_validation.c:2815:23 nginx#5 0x55dd798d6f84 in nxt_conf_vldt_access_log unit/src/nxt_conf_validation.c:3426:11 nginx#6 0x55dd798d55f4 in nxt_conf_vldt_object unit/src/nxt_conf_validation.c:2815:23 nginx#7 0x55dd798d47bd in nxt_conf_validate unit/src/nxt_conf_validation.c:1421:11 nginx#8 0x55dd79871c82 in LLVMFuzzerTestOneInput unit/fuzzing/nxt_json_fuzz.c:67:5 nginx#9 0x55dd79770620 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13 nginx#10 0x55dd7975adb4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6 nginx#11 0x55dd7976084a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9 nginx#12 0x55dd7978cc42 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 nginx#13 0x7e8192213082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16 nginx#14 0x55dd7975188d in _start Uninitialized value was created by an allocation of 'error.i' in the stack frame #0 0x55dd798dd42b in nxt_conf_vldt_var unit/src/nxt_conf_validation.c:1557:5 #1 0x55dd798dd42b in nxt_conf_vldt_if unit/src/nxt_conf_validation.c:1592:16 The issue was in nxt_tstr_test() where we create an error message with nxt_sprintf(), where this error message is then later used with the '%s' format specifier which expects a nul-terminated string, but by default nxt_sprintf() doesn't nul-terminate, you must use the '%Z' specifier to signify a '\0' at the end of the string. Link: <https://github.com/google/oss-fuzz> Link: <https://oss-fuzz.com/testcase-detail/5545917827055616> Co-developed-by: Zhidao HONG <[email protected]> Signed-off-by: Zhidao HONG <[email protected]> Reviewed-by: Andrew Clayton <[email protected]> Signed-off-by: Arjun <[email protected]> [ Commit message/subject - Andrew ] Signed-off-by: Andrew Clayton <[email protected]>
ac000
pushed a commit
to ac000/unit
that referenced
this issue
Jun 25, 2024
This issue was found with oss-fuzz. ==18420==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x55dd798a5797 in nxt_vsprintf unit/src/nxt_sprintf.c:163:31 #1 0x55dd798d5bdb in nxt_conf_vldt_error unit/src/nxt_conf_validation.c:1525:11 #2 0x55dd798dd4cd in nxt_conf_vldt_var unit/src/nxt_conf_validation.c:1560:16 #3 0x55dd798dd4cd in nxt_conf_vldt_if unit/src/nxt_conf_validation.c:1592:16 nginx#4 0x55dd798d55f4 in nxt_conf_vldt_object unit/src/nxt_conf_validation.c:2815:23 nginx#5 0x55dd798d6f84 in nxt_conf_vldt_access_log unit/src/nxt_conf_validation.c:3426:11 nginx#6 0x55dd798d55f4 in nxt_conf_vldt_object unit/src/nxt_conf_validation.c:2815:23 nginx#7 0x55dd798d47bd in nxt_conf_validate unit/src/nxt_conf_validation.c:1421:11 nginx#8 0x55dd79871c82 in LLVMFuzzerTestOneInput unit/fuzzing/nxt_json_fuzz.c:67:5 nginx#9 0x55dd79770620 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13 nginx#10 0x55dd7975adb4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6 nginx#11 0x55dd7976084a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9 nginx#12 0x55dd7978cc42 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 nginx#13 0x7e8192213082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16 nginx#14 0x55dd7975188d in _start Uninitialized value was created by an allocation of 'error.i' in the stack frame #0 0x55dd798dd42b in nxt_conf_vldt_var unit/src/nxt_conf_validation.c:1557:5 #1 0x55dd798dd42b in nxt_conf_vldt_if unit/src/nxt_conf_validation.c:1592:16 The issue was in nxt_tstr_test() where we create an error message with nxt_sprintf(), where this error message is then later used with the '%s' format specifier which expects a nul-terminated string, but by default nxt_sprintf() doesn't nul-terminate, you must use the '%Z' specifier to signify a '\0' at the end of the string. Signed-off-by: Arjun <[email protected]> Co-developed-by: Zhidao HONG <[email protected]> Signed-off-by: Zhidao HONG <[email protected]> Link: <https://github.com/google/oss-fuzz> Link: <https://oss-fuzz.com/testcase-detail/5545917827055616> Reviewed-by: Andrew Clayton <[email protected]> [ Commit message/subject - Andrew ] Signed-off-by: Andrew Clayton <[email protected]>
ac000
pushed a commit
to ac000/unit
that referenced
this issue
Jun 25, 2024
This issue was found with oss-fuzz. ==18420==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x55dd798a5797 in nxt_vsprintf unit/src/nxt_sprintf.c:163:31 #1 0x55dd798d5bdb in nxt_conf_vldt_error unit/src/nxt_conf_validation.c:1525:11 #2 0x55dd798dd4cd in nxt_conf_vldt_var unit/src/nxt_conf_validation.c:1560:16 #3 0x55dd798dd4cd in nxt_conf_vldt_if unit/src/nxt_conf_validation.c:1592:16 nginx#4 0x55dd798d55f4 in nxt_conf_vldt_object unit/src/nxt_conf_validation.c:2815:23 nginx#5 0x55dd798d6f84 in nxt_conf_vldt_access_log unit/src/nxt_conf_validation.c:3426:11 nginx#6 0x55dd798d55f4 in nxt_conf_vldt_object unit/src/nxt_conf_validation.c:2815:23 nginx#7 0x55dd798d47bd in nxt_conf_validate unit/src/nxt_conf_validation.c:1421:11 nginx#8 0x55dd79871c82 in LLVMFuzzerTestOneInput unit/fuzzing/nxt_json_fuzz.c:67:5 nginx#9 0x55dd79770620 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13 nginx#10 0x55dd7975adb4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6 nginx#11 0x55dd7976084a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9 nginx#12 0x55dd7978cc42 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 nginx#13 0x7e8192213082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16 nginx#14 0x55dd7975188d in _start Uninitialized value was created by an allocation of 'error.i' in the stack frame #0 0x55dd798dd42b in nxt_conf_vldt_var unit/src/nxt_conf_validation.c:1557:5 #1 0x55dd798dd42b in nxt_conf_vldt_if unit/src/nxt_conf_validation.c:1592:16 The issue was in nxt_tstr_test() where we create an error message with nxt_sprintf(), where this error message is then later used with the '%s' format specifier which expects a nul-terminated string, but by default nxt_sprintf() doesn't nul-terminate, you must use the '%Z' specifier to signify a '\0' at the end of the string. Signed-off-by: Arjun <[email protected]> Co-developed-by: Zhidao HONG <[email protected]> Signed-off-by: Zhidao HONG <[email protected]> Link: <https://github.com/google/oss-fuzz> Reviewed-by: Andrew Clayton <[email protected]> [ Commit message/subject - Andrew ] Signed-off-by: Andrew Clayton <[email protected]>
ac000
added a commit
to ac000/unit
that referenced
this issue
Oct 16, 2024
Under Ubuntu 24.04 the pytest for test/test_php_isolation.py::test_php_isolation_rootfs fails due to Unit aborting (SIGABRT) in the PHP language module due to FORIFY_SOURCE hardening detecting a buffer overflow 2024/10/16 16:46:54 [info] 11661#11661 "phpinfo" application started *** buffer overflow detected ***: terminated 2024/10/16 16:46:54 [alert] 11660#11660 app process 11661 exited on signal 6 After spending an extraordinary amount of time faffing around with Ubuntu and pytests (they don't make for a pleasant combination) I was able to reproduce it. The crash was occurring here nginx#4 0x00007ebe818288ff in __GI_abort () at ./stdlib/abort.c:79 nginx#5 0x00007ebe818297b6 in __libc_message_impl ( fmt=fmt@entry=0x7ebe819ce765 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:132 nginx#6 0x00007ebe81936c19 in __GI___fortify_fail ( msg=msg@entry=0x7ebe819ce74c "buffer overflow detected") at ./debug/fortify_fail.c:24 nginx#7 0x00007ebe819365d4 in __GI___chk_fail () at ./debug/chk_fail.c:28 nginx#8 0x00007ebe8134a055 in mempcpy (__len=10, __src=0x7ebe8160ade8, __dest=0x571ba9bd0930) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:45 nginx#9 fake_data_segment (info=0x0, sysdb=0x571ba9bcf080) at /usr/src/php8.1-8.1.30-1+ubuntu24.04.1+deb.sury.org+1/ext/date/lib/parse_tz.c:921 nginx#10 timelib_builtin_db () at /usr/src/php8.1-8.1.30-1+ubuntu24.04.1+deb.sury.org+1/ext/date/lib/parse_tz.c:1084 nginx#11 0x00007ebe812e0885 in zm_info_date (zend_module=0x571ba9a14420) [Well as best as I can tell, as this is from the php 8.1 packages from <https://github.com/oerdnj/deb.sury.org>, I don't know where the packages (I'm assuming it's packages) shivammathur/setup-php@v2 installs come from.] So we get killed in fake_data_segment(), the thing is, that function (as well as timelib_builtin_db()) doesn't exist in upstream PHP. It turns out these come from a patch that is applied by distributions to make PHP use the system installed timezone database rather than the one built into PHP. I was unable to reproduce this with vanilla PHP 8.1. It can be triggered on affected builds with the following config { "listeners": { "[::1]:8080": { "pass": "applications/php" } }, "applications": { "php": { "type": "php", "root": "/app/php", "isolation": { "rootfs": "/tmp/unit-root", "namespaces": { "mount": true, "credential": true, "pid": true } } } } } The crux of the issue seems to come down to in this case PHP can't open the tz database as it's not contained in the new mount namespace. 190437 openat(AT_FDCWD, "/usr/share/zoneinfo/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory) 190437 openat(AT_FDCWD, "/usr/share/zoneinfo/zone.tab", O_RDONLY) = -1 ENOENT (No such file or directory) 190437 writev(2, [{iov_base="*** ", iov_len=4}, {iov_base="buffer overflow detected", iov_len=24}, {iov_base=" ***: terminated\n", iov_len=17}], 3) = 45 ... 190437 --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=2, si_uid=65534} --- 190437 +++ killed by SIGABRT +++ Specifically the issue is with the following code in the patch (certainly an earlier version of the patch, this is from a Debian patch <https://sources.debian.org/src/php8.2/8.2.20-1~deb12u1/debian/patches/0007-Add-support-for-use-of-the-system-timezone-database.patch/>) + data = malloc(3 * sysdb->index_size + 7); + + p = mempcpy(data, FAKE_HEADER, sizeof(FAKE_HEADER) - 1); If the zone file hasn't been found then sysdb->index_size is 0. So we malloc(3) a total of 7 bytes. However, sizeof(FAKE_HEADER) - 1 is 10. (Hence the __len=10 in the mempcpy(3) in the above backtrace). Of course 10 doesn't fit into 7 and the FORTIFY_SOURCE hardening kicks in and SIGABRTs the process. Now, it's worth noting that this issue doesn't occur with PHP 8.2 and 8.3. As can been seen from the Fedora patch for this <https://src.fedoraproject.org/rpms/php/blob/rawhide/f/php-8.4.0-systzdata-v24.patch> They actually have a fix incorporated r23: fix possible buffer overflow So the above patch now does + data = malloc(3 * sysdb->index_size + sizeof(FAKE_HEADER) - 1); + + p = mempcpy(data, FAKE_HEADER, sizeof(FAKE_HEADER) - 1); So you will always get at least the required 10 bytes allocated. I assume the PHP 8.2 & 8.3 packages either no longer use this patch or have the fixed version. I don't know... I haven't found the sources... Anyway the above was more about satisfying myself that the problem wasn't with Unit. PHP 8.1 is now in security maintenance mode and people are actively encouraged to upgrade to 8.2/8.3 So lets just remove 8.1 from our testing... [It's also worth noting that after all this, the ubuntu-latest runners seemed to have switched back from 24.04 to 22.04. However lets stick with this and the other ci fixes as who knows when it'll go back to 24.04 (or some other version) again...] Link: <https://www.php.net/supported-versions.php> Signed-off-by: Andrew Clayton <[email protected]>
avahahn
pushed a commit
to javorszky/unit
that referenced
this issue
Oct 22, 2024
Under Ubuntu 24.04 the pytest for test/test_php_isolation.py::test_php_isolation_rootfs fails due to Unit aborting (SIGABRT) in the PHP language module due to FORIFY_SOURCE hardening detecting a buffer overflow 2024/10/16 16:46:54 [info] 11661#11661 "phpinfo" application started *** buffer overflow detected ***: terminated 2024/10/16 16:46:54 [alert] 11660#11660 app process 11661 exited on signal 6 After spending an extraordinary amount of time faffing around with Ubuntu and pytests (they don't make for a pleasant combination) I was able to reproduce it. The crash was occurring here nginx#4 0x00007ebe818288ff in __GI_abort () at ./stdlib/abort.c:79 nginx#5 0x00007ebe818297b6 in __libc_message_impl ( fmt=fmt@entry=0x7ebe819ce765 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:132 nginx#6 0x00007ebe81936c19 in __GI___fortify_fail ( msg=msg@entry=0x7ebe819ce74c "buffer overflow detected") at ./debug/fortify_fail.c:24 nginx#7 0x00007ebe819365d4 in __GI___chk_fail () at ./debug/chk_fail.c:28 nginx#8 0x00007ebe8134a055 in mempcpy (__len=10, __src=0x7ebe8160ade8, __dest=0x571ba9bd0930) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:45 nginx#9 fake_data_segment (info=0x0, sysdb=0x571ba9bcf080) at /usr/src/php8.1-8.1.30-1+ubuntu24.04.1+deb.sury.org+1/ext/date/lib/parse_tz.c:921 nginx#10 timelib_builtin_db () at /usr/src/php8.1-8.1.30-1+ubuntu24.04.1+deb.sury.org+1/ext/date/lib/parse_tz.c:1084 nginx#11 0x00007ebe812e0885 in zm_info_date (zend_module=0x571ba9a14420) [Well as best as I can tell, as this is from the php 8.1 packages from <https://github.com/oerdnj/deb.sury.org>, I don't know where the packages (I'm assuming it's packages) shivammathur/setup-php@v2 installs come from.] So we get killed in fake_data_segment(), the thing is, that function (as well as timelib_builtin_db()) doesn't exist in upstream PHP. It turns out these come from a patch that is applied by distributions to make PHP use the system installed timezone database rather than the one built into PHP. I was unable to reproduce this with vanilla PHP 8.1. It can be triggered on affected builds with the following config { "listeners": { "[::1]:8080": { "pass": "applications/php" } }, "applications": { "php": { "type": "php", "root": "/app/php", "isolation": { "rootfs": "/tmp/unit-root", "namespaces": { "mount": true, "credential": true, "pid": true } } } } } The crux of the issue seems to come down to in this case PHP can't open the tz database as it's not contained in the new mount namespace. 190437 openat(AT_FDCWD, "/usr/share/zoneinfo/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory) 190437 openat(AT_FDCWD, "/usr/share/zoneinfo/zone.tab", O_RDONLY) = -1 ENOENT (No such file or directory) 190437 writev(2, [{iov_base="*** ", iov_len=4}, {iov_base="buffer overflow detected", iov_len=24}, {iov_base=" ***: terminated\n", iov_len=17}], 3) = 45 ... 190437 --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=2, si_uid=65534} --- 190437 +++ killed by SIGABRT +++ Specifically the issue is with the following code in the patch (certainly an earlier version of the patch, this is from a Debian patch <https://sources.debian.org/src/php8.2/8.2.20-1~deb12u1/debian/patches/0007-Add-support-for-use-of-the-system-timezone-database.patch/>) + data = malloc(3 * sysdb->index_size + 7); + + p = mempcpy(data, FAKE_HEADER, sizeof(FAKE_HEADER) - 1); If the zone file hasn't been found then sysdb->index_size is 0. So we malloc(3) a total of 7 bytes. However, sizeof(FAKE_HEADER) - 1 is 10. (Hence the __len=10 in the mempcpy(3) in the above backtrace). Of course 10 doesn't fit into 7 and the FORTIFY_SOURCE hardening kicks in and SIGABRTs the process. Now, it's worth noting that this issue doesn't occur with PHP 8.2 and 8.3. As can been seen from the Fedora patch for this <https://src.fedoraproject.org/rpms/php/blob/rawhide/f/php-8.4.0-systzdata-v24.patch> They actually have a fix incorporated r23: fix possible buffer overflow So the above patch now does + data = malloc(3 * sysdb->index_size + sizeof(FAKE_HEADER) - 1); + + p = mempcpy(data, FAKE_HEADER, sizeof(FAKE_HEADER) - 1); So you will always get at least the required 10 bytes allocated. I assume the PHP 8.2 & 8.3 packages either no longer use this patch or have the fixed version. I don't know... I haven't found the sources... Anyway the above was more about satisfying myself that the problem wasn't with Unit. PHP 8.1 is now in security maintenance mode and people are actively encouraged to upgrade to 8.2/8.3 So lets just remove 8.1 from our testing... [It's also worth noting that after all this, the ubuntu-latest runners seemed to have switched back from 24.04 to 22.04. However lets stick with this and the other ci fixes as who knows when it'll go back to 24.04 (or some other version) again...] Link: <https://www.php.net/supported-versions.php> Signed-off-by: Andrew Clayton <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Did a vanilla nginx/unit/php7/wordpress install on a fresh Ubuntu Xenial and noticed that I couldn't log in to wp-admin or post comments. Seems like $_POST doesn't get populated[1]?
Not sure if its a known issue, if it is you can just go ahead and close this. :)
[1]:
Did a simple test to verify:
test.php:
<?php print_r($_POST); ?>The text was updated successfully, but these errors were encountered: