Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update APRDesign.html #14

Open
wants to merge 7,878 commits into
base: trunk
Choose a base branch
from
Open

Update APRDesign.html #14

wants to merge 7,878 commits into from

Conversation

ckant787
Copy link

i have found a mistake pls see it.

jimjag and others added 30 commits November 22, 2016 12:43
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1770832 13f79535-47bb-0310-9956-ffa450edef68
…e pool

given to crypto_key()/crypto_passphrase().



git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1772414 13f79535-47bb-0310-9956-ffa450edef68
Patch by Hanno Böck


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1772803 13f79535-47bb-0310-9956-ffa450edef68
* file_io/win32/filestat.c
  (apr_file_info_get): Use GetFileSizeEx() instead of GetFileInformationByHandleEx()
   when only APR_FINFO_SIZE is requested.


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1774712 13f79535-47bb-0310-9956-ffa450edef68
webviewer:projectlanguage properties for TortoiseSVN.

git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1774713 13f79535-47bb-0310-9956-ffa450edef68
* mmap/win32/mmap.c
  (apr_mmap_create): Use CreateFileMappingW() if APR_HAS_UNICODE_FS and   
  IF_WIN_OS_IS_UNICODE.


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1774923 13f79535-47bb-0310-9956-ffa450edef68
As noticed by rjung, not all pthread implementations have mutex_timedlock(),
like Solaris 8, so proc_mutex_proc_pthread_timedacquire() can return
APR_ENOTIMPL.



git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1774973 13f79535-47bb-0310-9956-ffa450edef68
Wrong place for this check, and wrong value too (should be 1 << 17).
But actually the max is already caped by _crypt_gensalt_blowfish_rn()
which is necessarily called previously in apr_bcrypt_encode().



git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1774976 13f79535-47bb-0310-9956-ffa450edef68
the second/double proc_ (consistently with other mechanisms).



git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1775069 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1776994 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1778149 13f79535-47bb-0310-9956-ffa450edef68
Submitted by: Michal Karm Babacek <karm fedoraproject.org>
Reviewed by: ylavic


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1778153 13f79535-47bb-0310-9956-ffa450edef68
Still avoid excessive bcrypt iterations, verification side this time.



git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1781391 13f79535-47bb-0310-9956-ffa450edef68
…alling

apr_file_read() on each byte.

The benchmark shows that this makes the function roughly 4 times faster:

  4.202 ms -> 1.042 ms   (I measured multiple calls for the same test file)

Also see https://svn.apache.org/r65294

* file_io/win32/readwrite.c
  (apr_file_read): Factor out the part of this function that handles
   reading from buffered files ...
  (read_buffered): ...into this new helper.
  (apr_file_gets): Use the buffer directly for buffered files, the same
   way as in the Unix implementation.

* test/testfile.c
  (test_gets, test_gets_buffered): Extend these tests with read-after-EOF
   checks.
  (test_gets_empty, test_gets_multiline, test_gets_small_buf,
   test_gets_ungetc, test_gets_buffered_big): New tests.
  (testfile): Run the new tests.

Patch by: Evgeny Kotkov <evgeny.kotkov {at} visualsvn.com>


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1785072 13f79535-47bb-0310-9956-ffa450edef68
would be allocated for the given size (including the header and alignment).



git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1788334 13f79535-47bb-0310-9956-ffa450edef68
…gure

the size of the buffer used to read files.



git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1788335 13f79535-47bb-0310-9956-ffa450edef68
apr_allocator_min_order_set() and apr_pool_alloc_order_set() to
respectively get the (system's) page size in use, set the minimum
allocation size for an allocator and the pool default allocation
size (expressed in 2^order pages).



git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1788346 13f79535-47bb-0310-9956-ffa450edef68
…g for

allocators and pools, so axe apr_pool_alloc_order_set().



git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1788376 13f79535-47bb-0310-9956-ffa450edef68
minfrin and others added 27 commits August 30, 2018 12:19
caller to iterate through object key value pairs.


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1839675 13f79535-47bb-0310-9956-ffa450edef68
As a side effect, this removes the need for the temporary pool
during JSON decoding.


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1839735 13f79535-47bb-0310-9956-ffa450edef68
Make this clear in the API by requiring a usual string in apr_json_object_set()
and creating the apr_json_string_t from it.

It's also more user friendly as otherwise apr_json_string_create() is to be
used when setting an entry.

Also, axe the 'pool' arg from apr_json_array_add() since it's not needed.


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1839755 13f79535-47bb-0310-9956-ffa450edef68
…d in one

single case of user-provided input, to avoid an index into invalid memory.



git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1839769 13f79535-47bb-0310-9956-ffa450edef68
…ject valueT

The object key-value pair parsed by the JSON decoder contained pre/post spaces
which we lost by changing the key type (to a C string) in apr_json_object_set().

Add a new/private apr__json_object_set() helper taking an apr_json_value_t key
and use it in both apr_json_object_set() and apr_json_decode_object().


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1839779 13f79535-47bb-0310-9956-ffa450edef68
Signing and Encryption messages as per RFC7515, RFC7516, RFC7517
and RFC7519.


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1839819 13f79535-47bb-0310-9956-ffa450edef68
a simple key, and apr_json_object_set() with the key as an
apr_json_value_t, so the caller has a simpler interface to use to add
a key value pair to an object.


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1839840 13f79535-47bb-0310-9956-ffa450edef68
longer neceessary to pass in a pointer to a NULL pointer, but keep
supporting the option to pre-allocate structures.


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1839859 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1839872 13f79535-47bb-0310-9956-ffa450edef68
(when a jose structure has been created to carry the error message).


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1839897 13f79535-47bb-0310-9956-ffa450edef68
Submitted by: rjung


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1840372 13f79535-47bb-0310-9956-ffa450edef68
* dbd/apr_dbd_odbc.c (odbc_lob_bucket_read): Fix to allocate
  sizeof(apr_bucket) not sizeof(apr_bucket *).


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1842824 13f79535-47bb-0310-9956-ffa450edef68
asfgit pushed a commit that referenced this pull request Dec 16, 2020
apr_pools: lock parent pool in pool_destroy_debug().

By using apr_pool_clear_debug() instead of pool_clear_debug() in
pool_destroy_debug() we gain the locking provided by the former and thus
protection from concurrent access from apr_pool_walk_tree(), which is
undefined behaviour.

While pool_destroy_debug()=>apr_pool_clear_debug()=>pool_clear_debug() calls
pool_destroy_debug() for all the children pools, this does not cause a deadlock
because apr_pool_clear_debug() locks the parent pool only (not the pool itself)
and thus pool_destroy_debug(pool->child) locks the current pool with no issue.

This fixes use-after-free like the below in httpd (with -D APR_POOL_DEBUG):

=================================================================
==2026856==ERROR: AddressSanitizer: heap-use-after-free on address 0x60600025acf0 at pc 0x7fe738f4c5be bp 0x7fe718598110 sp 0x7fe718598108
READ of size 8 at 0x60600025acf0 thread T51
    #0 0x7fe738f4c5bd in apr_thread_mutex_lock locks/unix/thread_mutex.c:124
    #1 0x7fe738f4e01c in apr_pool_walk_tree memory/unix/apr_pools.c:1505
    #2 0x7fe738f4e066 in apr_pool_walk_tree memory/unix/apr_pools.c:1511
    #3 0x7fe738f4e066 in apr_pool_walk_tree memory/unix/apr_pools.c:1511
    #4 0x7fe738f4e066 in apr_pool_walk_tree memory/unix/apr_pools.c:1511
    #5 0x7fe738f5027c in apr_pool_find memory/unix/apr_pools.c:2291
    #6 0x7fe738f14aba in apr_table_mergen tables/apr_tables.c:746
    #7 0x5578ad926a25 in ap_set_keepalive /home/ylavic/src/apache/httpd/trunk/modules/http/http_protocol.c:309
    #8 0x5578ad93933f in ap_http_header_filter /home/ylavic/src/apache/httpd/trunk/modules/http/http_filters.c:1376
    #9 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
    #10 0x5578ad9a67f3 in ap_content_length_filter /home/ylavic/src/apache/httpd/trunk/server/protocol.c:2046
    #11 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
    #12 0x5578ad9405ae in ap_byterange_filter /home/ylavic/src/apache/httpd/trunk/modules/http/byterange_filter.c:463
    #13 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
    #14 0x7fe7330e398b in ap_headers_output_filter /home/ylavic/src/apache/httpd/trunk/modules/metadata/mod_headers.c:891
    #15 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
    #16 0x7fe732e32dba in session_output_filter /home/ylavic/src/apache/httpd/trunk/modules/session/mod_session.c:501
    #17 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
    #18 0x5578ad9c8ee5 in default_handler /home/ylavic/src/apache/httpd/trunk/server/core.c:5188
    #19 0x5578ad9431bb in ap_run_handler /home/ylavic/src/apache/httpd/trunk/server/config.c:170
    #20 0x5578ad944941 in ap_invoke_handler /home/ylavic/src/apache/httpd/trunk/server/config.c:444
    #21 0x5578ad92cc23 in ap_process_async_request /home/ylavic/src/apache/httpd/trunk/modules/http/http_request.c:463
    #22 0x5578ad924d7c in ap_process_http_async_connection /home/ylavic/src/apache/httpd/trunk/modules/http/http_core.c:158
    #23 0x5578ad925410 in ap_process_http_connection /home/ylavic/src/apache/httpd/trunk/modules/http/http_core.c:252
    #24 0x5578ad97e04d in ap_run_process_connection /home/ylavic/src/apache/httpd/trunk/server/connection.c:42
    #25 0x7fe735c7ef79 in process_socket /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:1097
    #26 0x7fe735c856a0 in worker_thread /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:2386
    #27 0x7fe738f7cef4 in dummy_worker threadproc/unix/thread.c:145
    #28 0x7fe738e3eea6 in start_thread nptl/pthread_create.c:477
    #29 0x7fe738d6ed4e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfdd4e)

0x60600025acf0 is located 48 bytes inside of 64-byte region [0x60600025acc0,0x60600025ad00)
freed by thread T63 here:
    #0 0x7fe7391ed277 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107277)
    #1 0x7fe738f4e9e5 in pool_clear_debug memory/unix/apr_pools.c:1893
    #2 0x7fe738f4ecb2 in pool_destroy_debug memory/unix/apr_pools.c:1956
    #3 0x7fe738f4eeeb in apr_pool_destroy_debug memory/unix/apr_pools.c:2002
    #4 0x5578ada2534b in ap_queue_info_push_pool /home/ylavic/src/apache/httpd/trunk/server/mpm_fdqueue.c:230
    #5 0x7fe735c81412 in process_lingering_close /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:1686
    #6 0x7fe735c7f9bc in process_socket /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:1255
    #7 0x7fe735c856a0 in worker_thread /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:2386
    #8 0x7fe738f7cef4 in dummy_worker threadproc/unix/thread.c:145
    #9 0x7fe738e3eea6 in start_thread nptl/pthread_create.c:477


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/branches/1.7.x@1883751 13f79535-47bb-0310-9956-ffa450edef68
asfgit pushed a commit that referenced this pull request Dec 16, 2020
By using apr_pool_clear_debug() instead of pool_clear_debug() in
pool_destroy_debug() we gain the locking provided by the former and thus
protection from concurrent access from apr_pool_walk_tree(), which is
undefined behaviour.

While pool_destroy_debug()=>apr_pool_clear_debug()=>pool_clear_debug() calls
pool_destroy_debug() for all the children pools, this does not cause a deadlock
because apr_pool_clear_debug() locks the parent pool only (not the pool itself)
and thus pool_destroy_debug(pool->child) locks the current pool with no issue.

This fixes use-after-free like the below in httpd (with -D APR_POOL_DEBUG):

=================================================================
==2026856==ERROR: AddressSanitizer: heap-use-after-free on address 0x60600025acf0 at pc 0x7fe738f4c5be bp 0x7fe718598110 sp 0x7fe718598108
READ of size 8 at 0x60600025acf0 thread T51
    #0 0x7fe738f4c5bd in apr_thread_mutex_lock locks/unix/thread_mutex.c:124
    #1 0x7fe738f4e01c in apr_pool_walk_tree memory/unix/apr_pools.c:1505
    #2 0x7fe738f4e066 in apr_pool_walk_tree memory/unix/apr_pools.c:1511
    #3 0x7fe738f4e066 in apr_pool_walk_tree memory/unix/apr_pools.c:1511
    #4 0x7fe738f4e066 in apr_pool_walk_tree memory/unix/apr_pools.c:1511
    #5 0x7fe738f5027c in apr_pool_find memory/unix/apr_pools.c:2291
    #6 0x7fe738f14aba in apr_table_mergen tables/apr_tables.c:746
    #7 0x5578ad926a25 in ap_set_keepalive /home/ylavic/src/apache/httpd/trunk/modules/http/http_protocol.c:309
    #8 0x5578ad93933f in ap_http_header_filter /home/ylavic/src/apache/httpd/trunk/modules/http/http_filters.c:1376
    #9 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
    #10 0x5578ad9a67f3 in ap_content_length_filter /home/ylavic/src/apache/httpd/trunk/server/protocol.c:2046
    #11 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
    #12 0x5578ad9405ae in ap_byterange_filter /home/ylavic/src/apache/httpd/trunk/modules/http/byterange_filter.c:463
    #13 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
    #14 0x7fe7330e398b in ap_headers_output_filter /home/ylavic/src/apache/httpd/trunk/modules/metadata/mod_headers.c:891
    #15 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
    #16 0x7fe732e32dba in session_output_filter /home/ylavic/src/apache/httpd/trunk/modules/session/mod_session.c:501
    #17 0x5578ad98f7bd in ap_pass_brigade /home/ylavic/src/apache/httpd/trunk/server/util_filter.c:783
    #18 0x5578ad9c8ee5 in default_handler /home/ylavic/src/apache/httpd/trunk/server/core.c:5188
    #19 0x5578ad9431bb in ap_run_handler /home/ylavic/src/apache/httpd/trunk/server/config.c:170
    #20 0x5578ad944941 in ap_invoke_handler /home/ylavic/src/apache/httpd/trunk/server/config.c:444
    #21 0x5578ad92cc23 in ap_process_async_request /home/ylavic/src/apache/httpd/trunk/modules/http/http_request.c:463
    #22 0x5578ad924d7c in ap_process_http_async_connection /home/ylavic/src/apache/httpd/trunk/modules/http/http_core.c:158
    #23 0x5578ad925410 in ap_process_http_connection /home/ylavic/src/apache/httpd/trunk/modules/http/http_core.c:252
    #24 0x5578ad97e04d in ap_run_process_connection /home/ylavic/src/apache/httpd/trunk/server/connection.c:42
    #25 0x7fe735c7ef79 in process_socket /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:1097
    #26 0x7fe735c856a0 in worker_thread /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:2386
    #27 0x7fe738f7cef4 in dummy_worker threadproc/unix/thread.c:145
    #28 0x7fe738e3eea6 in start_thread nptl/pthread_create.c:477
    #29 0x7fe738d6ed4e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfdd4e)

0x60600025acf0 is located 48 bytes inside of 64-byte region [0x60600025acc0,0x60600025ad00)
freed by thread T63 here:
    #0 0x7fe7391ed277 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107277)
    #1 0x7fe738f4e9e5 in pool_clear_debug memory/unix/apr_pools.c:1893
    #2 0x7fe738f4ecb2 in pool_destroy_debug memory/unix/apr_pools.c:1956
    #3 0x7fe738f4eeeb in apr_pool_destroy_debug memory/unix/apr_pools.c:2002
    #4 0x5578ada2534b in ap_queue_info_push_pool /home/ylavic/src/apache/httpd/trunk/server/mpm_fdqueue.c:230
    #5 0x7fe735c81412 in process_lingering_close /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:1686
    #6 0x7fe735c7f9bc in process_socket /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:1255
    #7 0x7fe735c856a0 in worker_thread /home/ylavic/src/apache/httpd/trunk/server/mpm/event/event.c:2386
    #8 0x7fe738f7cef4 in dummy_worker threadproc/unix/thread.c:145
    #9 0x7fe738e3eea6 in start_thread nptl/pthread_create.c:477


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1883750 13f79535-47bb-0310-9956-ffa450edef68
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.