Home
last modified time | relevance | path

Searched hist:4 (Results 101 – 125 of 326) sorted by relevance

12345678910>>...14

/unit/src/
H A Dnxt_thread_pool.hdiff 4:76c63e9b6322 Fri Jan 27 08:35:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Work queues refactoring.
H A Dnxt_process_title.cdiff 20:4dc92b438f58 Thu Mar 09 15:03:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Processes refactoring.
The cycle has been renamed to the runtime.
H A Dnxt_event_conn_job_sendfile.cdiff 20:4dc92b438f58 Thu Mar 09 15:03:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Processes refactoring.
The cycle has been renamed to the runtime.
diff 4:76c63e9b6322 Fri Jan 27 08:35:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Work queues refactoring.
H A Dnxt_log_moderation.cdiff 4:76c63e9b6322 Fri Jan 27 08:35:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Work queues refactoring.
H A Dnxt_http_rewrite.cdiff 2567:31a8f342d32a Wed Oct 04 23:36:00 UTC 2023 Andrew Clayton <a.clayton@nginx.com> HTTP: Fix URL with query string rewrite.

On Github, @rlandgrebe reported an issue when trying to rewrite URLs
that contained query strings.

With the PHP language module we were in fact segfaulting (SIGSEGV) in
libphp

[93960.462952] unitd[20940]: segfault at 7f307cef6476 ip 00007f2f81a94577 sp 00007fff28a777d0 error 4 in libphp-8.2.so[7f2f818df000+2fd000] likely on CPU 0 (core 0, socket 0)

#0 0x00007f2abd494577 in php_default_treat_data (arg=1, str=0x0,
destArray=<optimized out>)
at /usr/src/debug/php-8.2.10-1.fc38.x86_64/main/php_variables.c:488
488 if (c_var && *c_var) {
(gdb) p c_var
$1 = 0x7f2bb8880676 <error: Cannot access memory at address 0x7f2bb8880676>

This was when trying to get the query string which somehow is pointing
off into the woods.

This gdb debug session when doing rewrite basically shows the core of
the issue

(gdb) x /64bs req->fields
...
0x7f7eaaaa8090: "GET"
0x7f7eaaaa8094: "HTTP/1.1"
0x7f7eaaaa809d: "::1"
0x7f7eaaaa80a1: "::1"
0x7f7eaaaa80a5: "8080"
0x7f7eaaaa80aa: "localhost"
0x7f7eaaaa80b4: "/test?q=a"
0x7f7eaaaa80be: "/test"
...

(gdb) p target_pos
$4 = (void *) 0x7f7eaaaa80b4

(gdb) p query_pos
$6 = (void *) 0x7f7eaaaa6af6

(gdb) p r->args->start
$8 = (u_char *) 0x7f7ea4002b02 "q=a HTTP/1.1\r\nHost: localhost:8080\r\nUser-Agent: curl/8.0.1\r\nAccept: */*\r\n\r\n"
(gdb) p r->target.start
$9 = (u_char *) 0x7f7ea40040c0 "/test?q=a"

That last address, 0x7f7ea40040c0, looks out of wack, it should be
smaller than r->args->start.

That results in a calculation in nxt_router_prepare_msg()

if (r->args->start != NULL) {
query_pos = nxt_pointer_to(target_pos,
r->args->start - r->target.start);

nxt_unit_sptr_set(&req->query, query_pos);

} else {

that goes negative that then is stored in req->query.offset which is a
uint32_t and so wraps backwards from UINT_MAX to give us an offset of a
little under 4GiB, hence the above invalid memory access.

All this happens due to in nxt_http_rewrite() if we have a URL with a
query string, we create a new memory allocation to store the transformed
URL and query string.

We set r->target to point to this new allocation, but we also need to
point r->args->start to the start of the query string in this new
allocation.

Reported-by: René Landgrebe <https://github.com/rlandgrebe>
Tested-by: René Landgrebe <https://github.com/rlandgrebe>
Tested-by: Liam Crilly <liam.crilly@nginx.com>
Fixes: 14d6d97b ("HTTP: added basic URI rewrite.")
Closes: <https://github.com/nginx/unit/issues/964>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
diff 2567:31a8f342d32a Wed Oct 04 23:36:00 UTC 2023 Andrew Clayton <a.clayton@nginx.com> HTTP: Fix URL with query string rewrite.

On Github, @rlandgrebe reported an issue when trying to rewrite URLs
that contained query strings.

With the PHP language module we were in fact segfaulting (SIGSEGV) in
libphp

[93960.462952] unitd[20940]: segfault at 7f307cef6476 ip 00007f2f81a94577 sp 00007fff28a777d0 error 4 in libphp-8.2.so[7f2f818df000+2fd000] likely on CPU 0 (core 0, socket 0)

#0 0x00007f2abd494577 in php_default_treat_data (arg=1, str=0x0,
destArray=<optimized out>)
at /usr/src/debug/php-8.2.10-1.fc38.x86_64/main/php_variables.c:488
488 if (c_var && *c_var) {
(gdb) p c_var
$1 = 0x7f2bb8880676 <error: Cannot access memory at address 0x7f2bb8880676>

This was when trying to get the query string which somehow is pointing
off into the woods.

This gdb debug session when doing rewrite basically shows the core of
the issue

(gdb) x /64bs req->fields
...
0x7f7eaaaa8090: "GET"
0x7f7eaaaa8094: "HTTP/1.1"
0x7f7eaaaa809d: "::1"
0x7f7eaaaa80a1: "::1"
0x7f7eaaaa80a5: "8080"
0x7f7eaaaa80aa: "localhost"
0x7f7eaaaa80b4: "/test?q=a"
0x7f7eaaaa80be: "/test"
...

(gdb) p target_pos
$4 = (void *) 0x7f7eaaaa80b4

(gdb) p query_pos
$6 = (void *) 0x7f7eaaaa6af6

(gdb) p r->args->start
$8 = (u_char *) 0x7f7ea4002b02 "q=a HTTP/1.1\r\nHost: localhost:8080\r\nUser-Agent: curl/8.0.1\r\nAccept: */*\r\n\r\n"
(gdb) p r->target.start
$9 = (u_char *) 0x7f7ea40040c0 "/test?q=a"

That last address, 0x7f7ea40040c0, looks out of wack, it should be
smaller than r->args->start.

That results in a calculation in nxt_router_prepare_msg()

if (r->args->start != NULL) {
query_pos = nxt_pointer_to(target_pos,
r->args->start - r->target.start);

nxt_unit_sptr_set(&req->query, query_pos);

} else {

that goes negative that then is stored in req->query.offset which is a
uint32_t and so wraps backwards from UINT_MAX to give us an offset of a
little under 4GiB, hence the above invalid memory access.

All this happens due to in nxt_http_rewrite() if we have a URL with a
query string, we create a new memory allocation to store the transformed
URL and query string.

We set r->target to point to this new allocation, but we also need to
point r->args->start to the start of the query string in this new
allocation.

Reported-by: René Landgrebe <https://github.com/rlandgrebe>
Tested-by: René Landgrebe <https://github.com/rlandgrebe>
Tested-by: Liam Crilly <liam.crilly@nginx.com>
Fixes: 14d6d97b ("HTTP: added basic URI rewrite.")
Closes: <https://github.com/nginx/unit/issues/964>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
diff 2567:31a8f342d32a Wed Oct 04 23:36:00 UTC 2023 Andrew Clayton <a.clayton@nginx.com> HTTP: Fix URL with query string rewrite.

On Github, @rlandgrebe reported an issue when trying to rewrite URLs
that contained query strings.

With the PHP language module we were in fact segfaulting (SIGSEGV) in
libphp

[93960.462952] unitd[20940]: segfault at 7f307cef6476 ip 00007f2f81a94577 sp 00007fff28a777d0 error 4 in libphp-8.2.so[7f2f818df000+2fd000] likely on CPU 0 (core 0, socket 0)

#0 0x00007f2abd494577 in php_default_treat_data (arg=1, str=0x0,
destArray=<optimized out>)
at /usr/src/debug/php-8.2.10-1.fc38.x86_64/main/php_variables.c:488
488 if (c_var && *c_var) {
(gdb) p c_var
$1 = 0x7f2bb8880676 <error: Cannot access memory at address 0x7f2bb8880676>

This was when trying to get the query string which somehow is pointing
off into the woods.

This gdb debug session when doing rewrite basically shows the core of
the issue

(gdb) x /64bs req->fields
...
0x7f7eaaaa8090: "GET"
0x7f7eaaaa8094: "HTTP/1.1"
0x7f7eaaaa809d: "::1"
0x7f7eaaaa80a1: "::1"
0x7f7eaaaa80a5: "8080"
0x7f7eaaaa80aa: "localhost"
0x7f7eaaaa80b4: "/test?q=a"
0x7f7eaaaa80be: "/test"
...

(gdb) p target_pos
$4 = (void *) 0x7f7eaaaa80b4

(gdb) p query_pos
$6 = (void *) 0x7f7eaaaa6af6

(gdb) p r->args->start
$8 = (u_char *) 0x7f7ea4002b02 "q=a HTTP/1.1\r\nHost: localhost:8080\r\nUser-Agent: curl/8.0.1\r\nAccept: */*\r\n\r\n"
(gdb) p r->target.start
$9 = (u_char *) 0x7f7ea40040c0 "/test?q=a"

That last address, 0x7f7ea40040c0, looks out of wack, it should be
smaller than r->args->start.

That results in a calculation in nxt_router_prepare_msg()

if (r->args->start != NULL) {
query_pos = nxt_pointer_to(target_pos,
r->args->start - r->target.start);

nxt_unit_sptr_set(&req->query, query_pos);

} else {

that goes negative that then is stored in req->query.offset which is a
uint32_t and so wraps backwards from UINT_MAX to give us an offset of a
little under 4GiB, hence the above invalid memory access.

All this happens due to in nxt_http_rewrite() if we have a URL with a
query string, we create a new memory allocation to store the transformed
URL and query string.

We set r->target to point to this new allocation, but we also need to
point r->args->start to the start of the query string in this new
allocation.

Reported-by: René Landgrebe <https://github.com/rlandgrebe>
Tested-by: René Landgrebe <https://github.com/rlandgrebe>
Tested-by: Liam Crilly <liam.crilly@nginx.com>
Fixes: 14d6d97b ("HTTP: added basic URI rewrite.")
Closes: <https://github.com/nginx/unit/issues/964>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
/unit/test/ruby/hooks/
H A Don_thread_boot.rbdiff 1919:4db57d6df920 Wed Jul 21 14:53:00 UTC 2021 Oisin Canty <o.canty@f5.com> Tests: use mutex with multitthreaded Ruby hooks.

This commit fixes a rare crash that can occur when File.write is
called by many threads.
H A Don_thread_shutdown.rbdiff 1919:4db57d6df920 Wed Jul 21 14:53:00 UTC 2021 Oisin Canty <o.canty@f5.com> Tests: use mutex with multitthreaded Ruby hooks.

This commit fixes a rare crash that can occur when File.write is
called by many threads.
H A Dmultiple.rbdiff 1919:4db57d6df920 Wed Jul 21 14:53:00 UTC 2021 Oisin Canty <o.canty@f5.com> Tests: use mutex with multitthreaded Ruby hooks.

This commit fixes a rare crash that can occur when File.write is
called by many threads.
/unit/test/python/mirror/
H A Dwsgi.pydiff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
/unit/test/python/threads/
H A Dwsgi.pydiff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
H A Dasgi.pydiff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
/unit/test/python/ctx_iter_atexit/
H A Dwsgi.pydiff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
/unit/test/python/upload/
H A Dwsgi.pydiff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
/unit/test/python/iter_exception/
H A Dwsgi.pydiff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
/unit/test/python/user_group/
H A Dwsgi.pydiff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
/unit/test/python/delayed/
H A Dasgi.pydiff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
/unit/src/java/
H A Dnxt_jni_InputStream.c977:4f9268f27b57 Thu Feb 28 15:02:00 UTC 2019 Max Romanov <max.romanov@gmail.com> Introducing Java Servlet Container beta.
H A Dnxt_jni_Response.c977:4f9268f27b57 Thu Feb 28 15:02:00 UTC 2019 Max Romanov <max.romanov@gmail.com> Introducing Java Servlet Container beta.
/unit/test/python/input_readline_size/
H A Dwsgi.pydiff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.

Previously, it was necessary to support older versions of Python for
compatibility. F-strings were released in Python 3.6. Python 3.5 was
marked as unsupported by the end of 2020, so now it's possible to start
using f-strings safely for better readability and performance.
/unit/test/python/legacy/
H A Dasgi.pydiff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
/unit/test/python/legacy_force/
H A Dasgi.pydiff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
/unit/test/python/variables/
H A Dwsgi.pydiff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
/unit/auto/modules/
H A Djava_get_jar977:4f9268f27b57 Thu Feb 28 15:02:00 UTC 2019 Max Romanov <max.romanov@gmail.com> Introducing Java Servlet Container beta.
/unit/test/python/atexit/
H A Dwsgi.pydiff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
/unit/test/python/threading/
H A Dwsgi.pydiff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.

Previously, it was necessary to support older versions of Python for
compatibility. F-strings were released in Python 3.6. Python 3.5 was
marked as unsupported by the end of 2020, so now it's possible to start
using f-strings safely for better readability and performance.

12345678910>>...14