Mark Andrews
b0f477df87
Call nta_detach() before dns_view_weakdetach() so view is available.
...
(cherry picked from commit ea956976d1
2020-11-03 23:49:24 +11:00
Mark Andrews
903c1136ef
Handle DNS_R_NCACHENXRRSET in fetch_callback_{dnskey,validator}()
...
DNS_R_NCACHENXRRSET can be return when zones are in transition state
from being unsigned to signed and signed to unsigned. The validation
should be resumed and should result in a insecure answer.
(cherry picked from commit 718e597def
2020-10-30 08:21:43 +11:00
Mark Andrews
2a5d2c55aa
Hold qid->lock when calling deref_portentry() as
...
socket_search() need portentry to be unchanging.
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1 (mutexes: write M1):
#0 deref_portentry lib/dns/dispatch.c:630
#1 deactivate_dispsocket lib/dns/dispatch.c:861
#2 udp_recv lib/dns/dispatch.c:1105
#3 udp_exrecv lib/dns/dispatch.c:1028
#4 dispatch lib/isc/task.c:1152
#5 run lib/isc/task.c:1344
#6 <null> <null>
Previous read of size 8 at 0x000000000001 by thread T2 (mutexes: write M1, write M2):
#0 socket_search lib/dns/dispatch.c:661
#1 get_dispsocket lib/dns/dispatch.c:744
#2 dns_dispatch_addresponse lib/dns/dispatch.c:3120
#3 resquery_send lib/dns/resolver.c:2467
#4 fctx_query lib/dns/resolver.c:2217
#5 fctx_try lib/dns/resolver.c:4245
#6 fctx_timeout lib/dns/resolver.c:4570
#7 dispatch lib/isc/task.c:1152
#8 run lib/isc/task.c:1344
#9 <null> <null>
(cherry picked from commit 5c253c416d
2020-10-24 07:14:47 +11:00
Mark Andrews
2e264a4ae2
DNS_ZONEFLAG_NOIXFR should be DNS_ZONEFLG_NOIXFR
...
(cherry picked from commit 3a044444bd
2020-10-24 00:26:25 +11:00
Tinderbox User
44e91206a4
prep 9.16.8
2020-10-22 09:09:07 +02:00
Diego Fronza
7a3dbbc395
Fix transfer of glue records in stub zones if master has minimal-responses set
...
Stub zones don't make use of AXFR/IXFR for the transfering of zone
data, instead, a single query is issued to the master asking for
their nameserver records (NS).
That works fine unless master is configured with 'minimal-responses'
set to yes, in which case glue records are not provided by master
in the answer with nameservers authoritative for the zone, leaving
stub zones with incomplete databases.
This commit fix this problem in a simple way, when the answer with
the authoritative nameservers is received from master (stub_callback),
for each nameserver listed (save_nsrrset), a A and AAAA records for
the name is verified in the additional section, and if not present
a query is created to resolve the corresponsing missing glue.
A struct 'stub_cb_args' was added to keep relevant information for
performing a query, like TSIG key, udp size, dscp value, etc, this
information is borrowed from, and created within function 'ns_query',
where the resolving of nameserver from master starts.
A new field was added to the struct 'dns_stub', an atomic integer,
namely pending_requests, which is used to keep how many queries are
created when resolving nameserver addresses that were missing in
the glue.
When the value of pending_requests is zero we know we can release
resources, adjust zone timers, dump to zone file, etc.
2020-10-21 12:11:31 -03:00
Mark Andrews
84922b2dc7
Restore the dns_message_reset() call before the dns_dispatch_getnext()
...
This was accidentally lost in the process of moving rmessage from fctx
to query. Without this dns_message_setclass() will fail.
(cherry picked from commit 1f63bb15b3
2020-10-08 16:27:10 +11:00
Mark Andrews
33d7b5b56f
Silence Coverity REVERSE_INULL report
...
message does not need to be tested to NULL
(cherry picked from commit f0a66cb5aa
2020-10-06 23:37:13 +11:00
Matthijs Mekking
63652ca58f
Use explicit result codes for 'rndc dnssec' cmd
...
It is better to add new result codes than to overload existing codes.
(cherry picked from commit 70d1ec432f
2020-10-05 11:20:35 +02:00
Matthijs Mekking
6bbb2a8581
Various rndc dnssec -checkds fixes
...
While working on 'rndc dnssec -rollover' I noticed the following
(small) issues:
- The key files where updated with hints set to "-when" and that
should always be "now.
- The kasp system test did not properly update the test number when
calling 'rndc dnssec -checkds' (and ensuring that works).
- There was a missing ']' in the rndc.c help output.
(cherry picked from commit edc53fc416
2020-10-05 11:20:35 +02:00
Matthijs Mekking
5bbecc5116
Test rndc rollover inactive key
...
When users (accidentally) try to roll an inactive key, throw an error.
(cherry picked from commit fcd34abb9e
2020-10-05 11:20:35 +02:00
Matthijs Mekking
ad48f07c9a
Add manual key rollover logic
...
Add to the keymgr a function that will schedule a rollover. This
basically means setting the time when the key needs to retire,
and updating the key lifetime, then update the state file. The next
time that named runs the keymgr the new lifetime will be taken into
account.
(cherry picked from commit df8276aef0
2020-10-05 11:20:35 +02:00
Matthijs Mekking
79f9a5ddd5
Change condition for rndc dumpdb -expired
...
After backporting #1870 to 9.11-S I saw that the condition check there
is different than in the main branch. In 9.11-S "stale" can mean
stale and serve-stale, or not active (awaiting cleanup). In 9.16 and
later versions, "stale" is stale and serve-stale, and "ancient" means
not active (awaiting cleanup). An "ancient" RRset is one that is not
active (TTL expired) and is not eligble for serve-stale.
Update the condition for rndc dumpdb -expired to closer match what is
in 9.11-S.
(cherry picked from commit 5614454c3b
2020-10-05 10:46:14 +02:00
Matthijs Mekking
456925d6ec
Fix kasp min key size bug
...
The minimal size for RSASHA1, RSASHA256 is 512, but due to bad
assignment it was set to 1024.
(cherry picked from commit 7c555254fe
2020-10-02 10:18:59 +02:00
Matthijs Mekking
a63dad13da
Fix Ed25519 and Ed448 in dnssec-policy keymgr
...
The kasp code had bad implicit size values for the cryptographic
algorithms Ed25519 and Ed448. When creating keys they would never
match the dnssec-policy, leading to new attempts to create keys.
These algorithms were previously not yet added to the system tests,
due to lack of availability on some systems.
(cherry picked from commit 0e207392ec
2020-10-02 10:18:25 +02:00
Michał Kępień
9e62c206c6
Allow "order none" in "rrset-order" rules
...
named-checkconf treats the following configuration as valid:
options {
rrset-order {
order none;
};
};
Yet, the above configuration causes named to crash on startup with:
order.c:74: REQUIRE(mode == 0x00000800 || mode == 0x00000400 || mode == 0x00800000) failed, back trace
Add DNS_RDATASETATTR_NONE to the list of RRset ordering modes accepted
by dns_order_add() to allow "order none" to be used in "rrset-order"
rules. This both prevents the aforementioned crashes and addresses the
discrepancy between named-checkconf and named.
(cherry picked from commit dbcf683c1a
2020-10-02 08:50:51 +02:00
Ondřej Surý
50db10b7ca
Fix the clang 12 warnings with multi-line strings in string arrays
...
The clang 12 has a new warning that warns when using multi-line strings
in the string arrays, f.e.:
{ "aa",
"b"
"b",
"cc" }
would generate warning like this:
private_test.c:162:7: error: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Werror,-Wstring-concatenation]
"33333/RSASHA1" };
^
private_test.c:161:7: note: place parentheses around the string literal to silence warning
"Done removing signatures for key "
^
private_test.c:197:7: error: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Werror,-Wstring-concatenation]
"NSEC chain",
^
private_test.c:196:7: note: place parentheses around the string literal to silence warning
"Removing NSEC3 chain 1 0 30 DEAF / creating "
^
2 errors generated.
(cherry picked from commit 7b07f22969
2020-10-01 18:42:11 +02:00
Mark Andrews
2b4f4cbbd0
Add the ability select individual tests to rdata_test
...
(cherry picked from commit 6293682020
2020-10-01 22:57:47 +10:00
Mark Andrews
fc3cab22a4
Add missing rwlock calls when access keynode.initial and keynode.managed
...
WARNING: ThreadSanitizer: data race
Write of size 1 at 0x000000000001 by thread T1 (mutexes: write M1):
#0 dns_keynode_trust lib/dns/keytable.c:836
#1 keyfetch_done lib/dns/zone.c:10187
#2 dispatch lib/isc/task.c:1152
#3 run lib/isc/task.c:1344
#4 <null> <null>
Previous read of size 1 at 0x000000000001 by thread T2 (mutexes: read M2):
#0 keynode_dslist_totext lib/dns/keytable.c:682
#1 dns_keytable_totext lib/dns/keytable.c:732
#2 named_server_dumpsecroots bin/named/server.c:11357
#3 named_control_docommand bin/named/control.c:264
#4 control_command bin/named/controlconf.c:390
#5 dispatch lib/isc/task.c:1152
#6 run lib/isc/task.c:1344
#7 <null> <null>
Location is heap block of size 241 at 0x000000000010 allocated by thread T3:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:713
#2 mem_get lib/isc/mem.c:622
#3 mem_allocateunlocked lib/isc/mem.c:1268
#4 isc___mem_allocate lib/isc/mem.c:1288
#5 isc__mem_allocate lib/isc/mem.c:2453
#6 isc___mem_get lib/isc/mem.c:1037
#7 isc__mem_get lib/isc/mem.c:2432
#8 new_keynode lib/dns/keytable.c:346
#9 insert lib/dns/keytable.c:393
#10 dns_keytable_add lib/dns/keytable.c:421
#11 process_key bin/named/server.c:955
#12 load_view_keys bin/named/server.c:983
#13 configure_view_dnsseckeys bin/named/server.c:1140
#14 configure_view bin/named/server.c:5371
#15 load_configuration bin/named/server.c:9110
#16 loadconfig bin/named/server.c:10310
#17 named_server_reconfigcommand bin/named/server.c:10693
#18 named_control_docommand bin/named/control.c:250
#19 control_command bin/named/controlconf.c:390
#20 dispatch lib/isc/task.c:1152
#21 run lib/isc/task.c:1344
#22 <null> <null>
Mutex M1 is already destroyed.
Mutex M2 is already destroyed.
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:915
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:915
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
Thread T3 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:915
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
SUMMARY: ThreadSanitizer: data race lib/dns/keytable.c:836 in dns_keynode_trust
(cherry picked from commit 840cf7adb3
2020-10-01 18:14:37 +10:00
Ondřej Surý
f0989bdf03
The dns_message_create() cannot fail, change the return to void
...
The dns_message_create() function cannot soft fail (as all memory
allocations either succeed or cause abort), so we change the function to
return void and cleanup the calls.
(cherry picked from commit 33eefe9f85
2020-09-30 14:26:26 +02:00
Diego Fronza
f557681472
Properly handling dns_message_t shared references
...
This commit fix the problems that arose when moving the dns_message_t
object from fetchctx_t to the query structure.
Since the lifetime of query objects are different than that of a
fetchctx and the dns_message_t object held by the query may be being
used by some external module, e.g. validator, even after the query
may have been destroyed, propery handling of the references to the
message were added in this commit to avoid accessing an already
destroyed object.
Specifically, in rctx_done(), a reference to the message is attached
at the beginning of the function and detached at the end, since a
possible call to fctx_cancelquery() would release the dns_message_t
object, and in the next lines of code a call to rctx_nextserver()
or rctx_chaseds() would require a valid pointer to the same object.
In valcreate() a new reference is attached to the message object,
this ensures that if the corresponding query object is destroyed
before the validator attempts to access it, no invalid pointer
access occurs.
In validated() we have to attach a new reference to the message,
since we destroy the validator object at the beginning of the
function, and we need access to the message in the next lines of
the same function.
rctx_nextserver() and rctx_chaseds() functions were adapted to
receive a new parameter of dns_message_t* type, this was so they
could receive a valid reference to a dns_message_t since using the
response context respctx_t to access the message through
rctx->query->rmessage could lead to an already released reference
due to the query being canceled.
(cherry picked from commit cde6227a68
2020-09-30 11:35:11 +10:00
Diego Fronza
dfa2b7a247
Fix invalid dns message state in resolver's logic
...
The assertion failure REQUIRE(msg->state == DNS_SECTION_ANY), caused
by calling dns_message_setclass within function resquery_response()
in resolver.c, was happening due to wrong management of dns message_t
objects used to process responses to the queries issued by the
resolver.
Before the fix, a resolver's fetch context (fetchctx_t) would hold
a pointer to the message, this same reference would then be used
over all the attempts to resolve the query, trying next server,
etc... for this to work the message object would have it's state
reset between each iteration, marking it as ready for a new processing.
The problem arose in a scenario with many different forwarders
configured, managing the state of the dns_message_t object was
lacking better synchronization, which have led it to a invalid
dns_message_t state in resquery_response().
Instead of adding unnecessarily complex code to synchronize the
object, the dns_message_t object was moved from fetchctx_t structure
to the query structure, where it better belongs to, since each query
will produce a response, this way whenever a new query is created
an associated dns_messate_t is also created.
This commit deals mainly with moving the dns_message_t object from
fetchctx_t to the query structure.
(cherry picked from commit 02f9e125c1
2020-09-30 11:34:57 +10:00
Diego Fronza
da84f8d1fd
Refactored dns_message_t for using attach/detach semantics
...
This commit will be used as a base for the next code updates in
order to have a better control of dns_message_t objects' lifetime.
(cherry picked from commit 12d6d13100
2020-09-30 11:34:42 +10:00
Mark Andrews
0c5191f27a
Update comments to have binary notation
...
(cherry picked from commit 6727e23a47
2020-09-29 10:40:56 +10:00
Matthijs Mekking
f521948b2b
rndc dumpdb -expired: print when RRsets expired
...
When calling 'rndc dumpdb -expired', also print when the RRset expired.
(cherry picked from commit d14c2d0d73
2020-09-25 08:21:24 +02:00
Matthijs Mekking
02b53d38af
Handle ancient rrsets in bind_rdataset
...
An ancient RRset is one still in the cache but expired, and awaiting
cleanup.
(cherry picked from commit 388cc666e5
2020-09-25 08:21:02 +02:00
Matthijs Mekking
c139f1c23b
Include expired rdatasets in iteration functions
...
By changing the check in 'rdatasetiter_first' and 'rdatasetiter_next'
from "now > header->rdh_ttl" to "now - RBDTB_VIRTUAL > header->rdh_ttl"
we include expired rdataset entries so that they can be used for
"rndc dumpdb -expired".
(cherry picked from commit 17d5bd4493
2020-09-25 08:20:46 +02:00
Matthijs Mekking
d77283ff63
Add -expired flag to rndc dumpdb command
...
This flag is the same as -cache, but will use a different style format
that will also print expired entries (awaiting cleanup) from the cache.
(cherry picked from commit 8beda7d2ea
2020-09-25 08:20:02 +02:00
Mark Andrews
9bd58a1c7a
Address lock order inversions.
...
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock)
Cycle in lock order graph: M1 (0x000000000000) => M2 (0x000000000000) => M1
Mutex M2 acquired here while holding mutex M1 in thread T1:
#0 pthread_mutex_lock <null>
#1 dns_view_findzonecut lib/dns/view.c:1310:2
#2 fctx_create lib/dns/resolver.c:5070:13
#3 dns_resolver_createfetch lib/dns/resolver.c:10813:12
#4 dns_resolver_prime lib/dns/resolver.c:10442:12
#5 dns_view_find lib/dns/view.c:1176:4
#6 dbfind_name lib/dns/adb.c:3833:11
#7 dns_adb_createfind lib/dns/adb.c:3155:12
#8 findname lib/dns/resolver.c:3497:11
#9 fctx_getaddresses lib/dns/resolver.c:3808:3
#10 fctx_try lib/dns/resolver.c:4197:12
#11 fctx_start lib/dns/resolver.c:4824:4
#12 dispatch lib/isc/task.c:1152:7
#13 run lib/isc/task.c:1344:2
Mutex M1 previously acquired by the same thread here:
#0 pthread_mutex_lock <null>
#1 dns_resolver_createfetch lib/dns/resolver.c:10767:2
#2 dns_resolver_prime lib/dns/resolver.c:10442:12
#3 dns_view_find lib/dns/view.c:1176:4
#4 dbfind_name lib/dns/adb.c:3833:11
#5 dns_adb_createfind lib/dns/adb.c:3155:12
#6 findname lib/dns/resolver.c:3497:11
#7 fctx_getaddresses lib/dns/resolver.c:3808:3
#8 fctx_try lib/dns/resolver.c:4197:12
#9 fctx_start lib/dns/resolver.c:4824:4
#10 dispatch lib/isc/task.c:1152:7
#11 run lib/isc/task.c:1344:2
Mutex M1 acquired here while holding mutex M2 in thread T1:
#0 pthread_mutex_lock <null>
#1 dns_resolver_shutdown lib/dns/resolver.c:10530:4
#2 view_flushanddetach lib/dns/view.c:632:4
#3 dns_view_detach lib/dns/view.c:689:2
#4 qctx_destroy lib/ns/query.c:5152:2
#5 fetch_callback lib/ns/query.c:5749:3
#6 dispatch lib/isc/task.c:1152:7
#7 run lib/isc/task.c:1344:2
Mutex M2 previously acquired by the same thread here:
#0 pthread_mutex_lock <null>
#1 view_flushanddetach lib/dns/view.c:630:3
#2 dns_view_detach lib/dns/view.c:689:2
#3 qctx_destroy lib/ns/query.c:5152:2
#4 fetch_callback lib/ns/query.c:5749:3
#5 dispatch lib/isc/task.c:1152:7
#6 run lib/isc/task.c:1344:2
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) in pthread_mutex_lock
(cherry picked from commit a669c919c8
2020-09-23 01:49:56 +00:00
Mark Andrews
9e79a7d7ce
Clone the saved / query message buffers
...
The message buffer passed to ns__client_request is only valid for
the life of the the ns__client_request call. Save a copy of it
when we recurse or process a update as ns__client_request will
return before those operations complete.
(cherry picked from commit f0d9bf7c30
2020-09-23 11:17:23 +10:00
Mark Andrews
0b861934b4
Address lock-order-inversion
...
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock)
Cycle in lock order graph: M1 (0x000000000001) => M2 (0x000000000002) => M1
Mutex M2 acquired here while holding mutex M1 in thread T1:
#0 pthread_rwlock_wrlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:52:4
#2 zone_postload lib/dns/zone.c:5101:2
#3 receive_secure_db lib/dns/zone.c:16206:11
#4 dispatch lib/isc/task.c:1152:7
#5 run lib/isc/task.c:1344:2
Mutex M1 previously acquired by the same thread here:
#0 pthread_mutex_lock <null>
#1 receive_secure_db lib/dns/zone.c:16204:2
#2 dispatch lib/isc/task.c:1152:7
#3 run lib/isc/task.c:1344:2
Mutex M1 acquired here while holding mutex M2 in thread T1:
#0 pthread_mutex_lock <null>
#1 get_raw_serial lib/dns/zone.c:2518:2
#2 zone_gotwritehandle lib/dns/zone.c:2559:4
#3 dispatch lib/isc/task.c:1152:7
#4 run lib/isc/task.c:1344:2
Mutex M2 previously acquired by the same thread here:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 zone_gotwritehandle lib/dns/zone.c:2552:2
#3 dispatch lib/isc/task.c:1152:7
#4 run lib/isc/task.c:1344:2
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) in pthread_rwlock_wrlock
(cherry picked from commit 1090876693
2020-09-22 22:26:53 +10:00
Mark Andrews
d04d43c777
Remove the memmove call on dns_rbtnode_t structure that contains atomics
...
Calling the plain memmove on the structure that contains atomic members
triggers following TSAN warning (even when we don't really use the
atomic members in the code):
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by thread T1 (mutexes: write M1, write M2):
#0 memmove <null>
#1 memmove /usr/include/x86_64-linux-gnu/bits/string_fortified.h:40:10
#2 deletefromlevel lib/dns/rbt.c:2675:3
#3 dns_rbt_deletenode lib/dns/rbt.c:2143:2
#4 delete_node lib/dns/rbtdb.c
#5 decrement_reference lib/dns/rbtdb.c:2202:4
#6 prune_tree lib/dns/rbtdb.c:2259:3
#7 dispatch lib/isc/task.c:1152:7
#8 run lib/isc/task.c:1344:2
Previous atomic write of size 8 at 0x000000000001 by thread T2 (mutexes: read M3):
#0 __tsan_atomic64_fetch_sub <null>
#1 decrement_reference lib/dns/rbtdb.c:2103:7
#2 detachnode lib/dns/rbtdb.c:5440:6
#3 dns_db_detachnode lib/dns/db.c:588:2
#4 qctx_clean lib/ns/query.c:5104:3
#5 ns_query_done lib/ns/query.c:10868:2
#6 query_sign_nodata lib/ns/query.c
#7 query_nodata lib/ns/query.c:8438:11
#8 query_gotanswer lib/ns/query.c
#9 query_lookup lib/ns/query.c:5624:10
#10 ns__query_start lib/ns/query.c:5500:10
#11 query_setup lib/ns/query.c:5224:11
#12 ns_query_start lib/ns/query.c:11357:8
#13 ns__client_request lib/ns/client.c:2166:3
#14 udp_recv_cb lib/isc/netmgr/udp.c:414:2
#15 uv__udp_recvmsg /home/ondrej/Projects/tsan/libuv/src/unix/udp.c
#16 uv__udp_io /home/ondrej/Projects/tsan/libuv/src/unix/udp.c:180:5
#17 uv__io_poll /home/ondrej/Projects/tsan/libuv/src/unix/linux-core.c:461:11
#18 uv_run /home/ondrej/Projects/tsan/libuv/src/unix/core.c:385:5
#19 nm_thread lib/isc/netmgr/netmgr.c:500:11
Location is heap block of size 132 at 0x000000000030 allocated by thread T3:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:713:8
#2 mem_get lib/isc/mem.c:622:8
#3 mem_allocateunlocked lib/isc/mem.c:1268:8
#4 isc___mem_allocate lib/isc/mem.c:1288:7
#5 isc__mem_allocate lib/isc/mem.c:2453:10
#6 isc___mem_get lib/isc/mem.c:1037:11
#7 isc__mem_get lib/isc/mem.c:2432:10
#8 create_node lib/dns/rbt.c:2239:9
#9 dns_rbt_addnode lib/dns/rbt.c:1435:12
#10 findnodeintree lib/dns/rbtdb.c:2895:12
#11 findnode lib/dns/rbtdb.c:2941:10
#12 dns_db_findnode lib/dns/db.c:439:11
#13 diff_apply lib/dns/diff.c:306:5
#14 dns_diff_apply lib/dns/diff.c:459:10
#15 do_one_tuple lib/ns/update.c:444:11
#16 update_one_rr lib/ns/update.c:495:10
#17 update_action lib/ns/update.c:3123:6
#18 dispatch lib/isc/task.c:1152:7
#19 run lib/isc/task.c:1344:2
Mutex M1 is already destroyed.
Mutex M2 is already destroyed.
Mutex M3 is already destroyed.
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_nm_start lib/isc/netmgr/netmgr.c:223:3
#3 create_managers bin/named/main.c:909:15
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
Thread T3 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
SUMMARY: ThreadSanitizer: data race in memmove
(cherry picked from commit 48d54368d5
2020-09-21 19:21:28 +10:00
Michał Kępień
170b869294
Fix updating summary RPZ DB for mixed-case RPZs
...
Each dns_rpz_zone_t structure keeps a hash table of the names this RPZ
database contains. Here is what happens when an RPZ is updated:
- a new hash table is prepared for the new version of the RPZ by
iterating over it; each name found is added to the summary RPZ
database,
- every name added to the new hash table is searched for in the old
hash table; if found, it is removed from the old hash table,
- the old hash table is iterated over; all names found in it are
removed from the summary RPZ database (because at that point the old
hash table should only contain names which are not present in the
new version of the RPZ),
- the new hash table replaces the old hash table.
When the new version of the RPZ is iterated over, if a given name is
spelled using a different letter case than in the old version of the
RPZ, the new variant will hash to a different value than the old
variant, which means it will not be removed from the old hash table.
When the old hash table is subsequently iterated over to remove
seemingly deleted names, the old variant of the name will still be
there, causing the name to be deleted from the summary RPZ database
(which effectively causes a given rule to be ignored).
The issue can be triggered not just by altering the case of existing
names in an RPZ, but also by adding sibling names spelled with a
different letter case. This is because RBT code preserves case when
node splitting occurs. The end result is that when the RPZ is iterated
over, a given name may be using a different case than in the zone file
(or XFR contents).
Fix by downcasing all names found in the RPZ database before adding them
to the summary RPZ database.
(cherry picked from commit dc8a7791bd
2020-09-21 09:32:21 +02:00
Mark Andrews
b7b0a4d71f
Pause dbiterator ealier to prevent lock-order-inversion
...
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock)
Cycle in lock order graph: M1 (0x000000000000) => M2 (0x000000000000) => M1
Mutex M2 acquired here while holding mutex M1 in thread T1:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 findnodeintree lib/dns/rbtdb.c:2877:2
#3 findnode lib/dns/rbtdb.c:2941:10
#4 dns_db_findnode lib/dns/db.c:439:11
#5 resume_addnsec3chain lib/dns/zone.c:3776:11
#6 rss_post lib/dns/zone.c:20659:3
#7 setnsec3param lib/dns/zone.c:20471:3
#8 dispatch lib/isc/task.c:1152:7
#9 run lib/isc/task.c:1344:2
Mutex M1 previously acquired by the same thread here:
#0 pthread_mutex_lock <null>
#1 rss_post lib/dns/zone.c:20658:3
#2 setnsec3param lib/dns/zone.c:20471:3
#3 dispatch lib/isc/task.c:1152:7
#4 run lib/isc/task.c:1344:2
Mutex M1 acquired here while holding mutex M2 in thread T2:
#0 pthread_mutex_lock <null>
#1 zone_nsec3chain lib/dns/zone.c:8666:5
#2 zone_maintenance lib/dns/zone.c:11063:4
#3 zone_timer lib/dns/zone.c:14098:2
#4 dispatch lib/isc/task.c:1152:7
#5 run lib/isc/task.c:1344:2
Mutex M2 previously acquired by the same thread here:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 resume_iteration lib/dns/rbtdb.c:9357:2
#3 dbiterator_next lib/dns/rbtdb.c:9647:3
#4 dns_dbiterator_next lib/dns/dbiterator.c:87:10
#5 zone_nsec3chain lib/dns/zone.c:8656:13
#6 zone_maintenance lib/dns/zone.c:11063:4
#7 zone_timer lib/dns/zone.c:14098:2
#8 dispatch lib/isc/task.c:1152:7
#9 run lib/isc/task.c:1344:2
(cherry picked from commit 9e584a4511
2020-09-17 18:24:07 +10:00
Mark Andrews
6edd349af5
Pause the database iterator to release rwlock
...
(cherry picked from commit 2e63de94aa
2020-09-17 18:24:07 +10:00
Mark Andrews
5cdc4671ec
Pause dbiterator to release rwlock to prevent lock-order-inversion.
...
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock)
Cycle in lock order graph: M1 (0x000000000000) => M2 (0x000000000001) => M1
Mutex M2 acquired here while holding mutex M1 in thread T1:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 getsigningtime lib/dns/rbtdb.c:8198:2
#3 dns_db_getsigningtime lib/dns/db.c:979:11
#4 set_resigntime lib/dns/zone.c:3887:11
#5 dns_zone_markdirty lib/dns/zone.c:11119:4
#6 update_action lib/ns/update.c:3376:3
#7 dispatch lib/isc/task.c:1152:7
#8 run lib/isc/task.c:1344:2
Mutex M1 previously acquired by the same thread here:
#0 pthread_mutex_lock <null>
#1 dns_zone_markdirty lib/dns/zone.c:11089:2
#2 update_action lib/ns/update.c:3376:3
#3 dispatch lib/isc/task.c:1152:7
#4 run lib/isc/task.c:1344:2
Mutex M1 acquired here while holding mutex M2 in thread T1:
#0 pthread_mutex_lock <null>
#1 zone_nsec3chain lib/dns/zone.c:8502:3
#2 zone_maintenance lib/dns/zone.c:11056:4
#3 zone_timer lib/dns/zone.c:14091:2
#4 dispatch lib/isc/task.c:1152:7
#5 run lib/isc/task.c:1344:2
Mutex M2 previously acquired by the same thread here:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 resume_iteration lib/dns/rbtdb.c:9357:2
#3 dbiterator_current lib/dns/rbtdb.c:9695:3
#4 dns_dbiterator_current lib/dns/dbiterator.c:101:10
#5 zone_nsec3chain lib/dns/zone.c:8539:3
#6 zone_maintenance lib/dns/zone.c:11056:4
#7 zone_timer lib/dns/zone.c:14091:2
#8 dispatch lib/isc/task.c:1152:7
#9 run lib/isc/task.c:1344:2
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) in pthread_rwlock_rdlock
(cherry picked from commit fbed962204
2020-09-17 18:24:07 +10:00
Mark Andrews
02f09ac566
Pause dbiterator to release rwlock to prevent lock-order-inversion.
...
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock)
Cycle in lock order graph: M1 (0x000000000001) => M2 (0x000000000000) => M1
Mutex M2 acquired here while holding mutex M1 in thread T1:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 zone_sign lib/dns/zone.c:9247:3
#3 zone_maintenance lib/dns/zone.c:11047:4
#4 zone_timer lib/dns/zone.c:14090:2
#5 dispatch lib/isc/task.c:1152:7
#6 run lib/isc/task.c:1344:2
Mutex M1 previously acquired by the same thread here:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 resume_iteration lib/dns/rbtdb.c:9357:2
#3 dbiterator_next lib/dns/rbtdb.c:9647:3
#4 dns_dbiterator_next lib/dns/dbiterator.c:87:10
#5 zone_sign lib/dns/zone.c:9488:13
#6 zone_maintenance lib/dns/zone.c:11047:4
#7 zone_timer lib/dns/zone.c:14090:2
#8 dispatch lib/isc/task.c:1152:7
#9 run lib/isc/task.c:1344:2
Mutex M1 acquired here while holding mutex M2 in thread T2:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 findnodeintree lib/dns/rbtdb.c:2877:2
#3 findnode lib/dns/rbtdb.c:2941:10
#4 dns_db_findnode lib/dns/db.c:439:11
#5 dns_db_getsoaserial lib/dns/db.c:780:11
#6 dump_done lib/dns/zone.c:11428:15
#7 dump_quantum lib/dns/masterdump.c:1487:2
#8 dispatch lib/isc/task.c:1152:7
#9 run lib/isc/task.c:1344:2
Mutex M2 previously acquired by the same thread here:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 dump_done lib/dns/zone.c:11426:4
#3 dump_quantum lib/dns/masterdump.c:1487:2
#4 dispatch lib/isc/task.c:1152:7
#5 run lib/isc/task.c:1344:2
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) in pthread_rwlock_rdlock
(cherry picked from commit c9dbad97b2
2020-09-17 18:24:07 +10:00
Mark Andrews
d36b4ed8ed
Pause dbiterator to release rwlock to prevent lock-order-inversion.
...
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock)
Cycle in lock order graph: M1 (0x000000000000) => M2 (0x000000000000) => M1
Mutex M2 acquired here while holding mutex M1 in thread T1:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 getsigningtime lib/dns/rbtdb.c:8198:2
#3 dns_db_getsigningtime lib/dns/db.c:979:11
#4 set_resigntime lib/dns/zone.c:3887:11
#5 dns_zone_markdirty lib/dns/zone.c:11115:4
#6 update_action lib/ns/update.c:3376:3
#7 dispatch lib/isc/task.c:1152:7
#8 run lib/isc/task.c:1344:2
Mutex M1 previously acquired by the same thread here:
#0 pthread_mutex_lock <null>
#1 dns_zone_markdirty lib/dns/zone.c:11085:2
#2 update_action lib/ns/update.c:3376:3
#3 dispatch lib/isc/task.c:1152:7
#4 run lib/isc/task.c:1344:2
Mutex M1 acquired here while holding mutex M2 in thread T2:
#0 pthread_mutex_lock <null>
#1 zone_nsec3chain lib/dns/zone.c:8274:3
#2 zone_maintenance lib/dns/zone.c:11052:4
#3 zone_timer lib/dns/zone.c:14087:2
#4 dispatch lib/isc/task.c:1152:7
#5 run lib/isc/task.c:1344:2
Mutex M2 previously acquired by the same thread here:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 resume_iteration lib/dns/rbtdb.c:9357:2
#3 dbiterator_next lib/dns/rbtdb.c:9647:3
#4 dns_dbiterator_next lib/dns/dbiterator.c:87:10
#5 zone_nsec3chain lib/dns/zone.c:8412:13
#6 zone_maintenance lib/dns/zone.c:11052:4
#7 zone_timer lib/dns/zone.c:14087:2
#8 dispatch lib/isc/task.c:1152:7
#9 run lib/isc/task.c:1344:2
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) in pthread_rwlock_rdlock
(cherry picked from commit 98025e15d0
2020-09-17 18:24:07 +10:00
Mark Andrews
6a1cd20473
Pause dbiterator to release rwlock to prevent lock-order-inversion.
...
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock)
Cycle in lock order graph: M1 (0x000000000001) => M2 (0x000000000002) => M3 (0x000000000000) => M1
Mutex M2 acquired here while holding mutex M1 in thread T1:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 findnodeintree lib/dns/rbtdb.c:2877:2
#3 findnode lib/dns/rbtdb.c:2941:10
#4 dns_db_findnode lib/dns/db.c:439:11
#5 copy_non_dnssec_records lib/dns/zone.c:16031:11
#6 receive_secure_db lib/dns/zone.c:16163:12
#7 dispatch lib/isc/task.c:1152:7
#8 run lib/isc/task.c:1344:2
Mutex M1 previously acquired by the same thread here:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 resume_iteration lib/dns/rbtdb.c:9357:2
#3 dbiterator_first lib/dns/rbtdb.c:9407:3
#4 dns_dbiterator_first lib/dns/dbiterator.c:43:10
#5 receive_secure_db lib/dns/zone.c:16160:16
#6 dispatch lib/isc/task.c:1152:7
#7 run lib/isc/task.c:1344:2
Mutex M3 acquired here while holding mutex M2 in thread T2:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 zone_sign lib/dns/zone.c:9244:3
#3 zone_maintenance lib/dns/zone.c:11044:4
#4 zone_timer lib/dns/zone.c:14087:2
#5 dispatch lib/isc/task.c:1152:7
#6 run lib/isc/task.c:1344:2
Mutex M2 previously acquired by the same thread here:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 resume_iteration lib/dns/rbtdb.c:9357:2
#3 dbiterator_next lib/dns/rbtdb.c:9647:3
#4 dns_dbiterator_next lib/dns/dbiterator.c:87:10
#5 zone_sign lib/dns/zone.c:9485:13
#6 zone_maintenance lib/dns/zone.c:11044:4
#7 zone_timer lib/dns/zone.c:14087:2
#8 dispatch lib/isc/task.c:1152:7
#9 run lib/isc/task.c:1344:2
Mutex M1 acquired here while holding mutex M3 in thread T3:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 findnodeintree lib/dns/rbtdb.c:2877:2
#3 findnode lib/dns/rbtdb.c:2941:10
#4 dns_db_findnode lib/dns/db.c:439:11
#5 zone_get_from_db lib/dns/zone.c:5602:11
#6 get_raw_serial lib/dns/zone.c:2520:12
#7 zone_gotwritehandle lib/dns/zone.c:2559:4
#8 dispatch lib/isc/task.c:1152:7
#9 run lib/isc/task.c:1344:2
Mutex M3 previously acquired by the same thread here:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 zone_gotwritehandle lib/dns/zone.c:2552:2
#3 dispatch lib/isc/task.c:1152:7
#4 run lib/isc/task.c:1344:2
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
Thread T3 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) in pthread_rwlock_rdlock
(cherry picked from commit e185e37137
2020-09-17 18:24:06 +10:00
Mark Andrews
f5a8d9055f
Address lock-order-inversion between the keytable and the db locks.
...
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock)
Cycle in lock order graph: M1 (0x000000000000) => M2 (0x000000000000) => M1
Mutex M2 acquired here while holding mutex M1 in thread T1:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 dns_keytable_find lib/dns/keytable.c:522:2
#3 sync_keyzone lib/dns/zone.c:4560:12
#4 dns_zone_synckeyzone lib/dns/zone.c:4635:11
#5 mkey_refresh bin/named/server.c:15423:2
#6 named_server_mkeys bin/named/server.c:15727:4
#7 named_control_docommand bin/named/control.c:236:12
#8 control_command bin/named/controlconf.c:365:17
#9 dispatch lib/isc/task.c:1152:7
#10 run lib/isc/task.c:1344:2
Mutex M1 previously acquired by the same thread here:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 resume_iteration lib/dns/rbtdb.c:9357:2
#3 dbiterator_first lib/dns/rbtdb.c:9407:3
#4 dns_dbiterator_first lib/dns/dbiterator.c:43:10
#5 dns_rriterator_first lib/dns/rriterator.c:71:15
#6 sync_keyzone lib/dns/zone.c:4543:16
#7 dns_zone_synckeyzone lib/dns/zone.c:4635:11
#8 mkey_refresh bin/named/server.c:15423:2
#9 named_server_mkeys bin/named/server.c:15727:4
#10 named_control_docommand bin/named/control.c:236:12
#11 control_command bin/named/controlconf.c:365:17
#12 dispatch lib/isc/task.c:1152:7
#13 run lib/isc/task.c:1344:2
Mutex M1 acquired here while holding mutex M2 in thread T1:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 zone_find lib/dns/rbtdb.c:4029:2
#3 dns_db_find lib/dns/db.c:500:11
#4 addifmissing lib/dns/zone.c:4481:11
#5 dns_keytable_forall lib/dns/keytable.c:786:4
#6 sync_keyzone lib/dns/zone.c:4586:2
#7 dns_zone_synckeyzone lib/dns/zone.c:4635:11
#8 mkey_refresh bin/named/server.c:15423:2
#9 named_server_mkeys bin/named/server.c:15727:4
#10 named_control_docommand bin/named/control.c:236:12
#11 control_command bin/named/controlconf.c:365:17
#12 dispatch lib/isc/task.c:1152:7
#13 run lib/isc/task.c:1344:2
Mutex M2 previously acquired by the same thread here:
#0 pthread_rwlock_rdlock <null>
#1 isc_rwlock_lock lib/isc/rwlock.c:48:3
#2 dns_keytable_forall lib/dns/keytable.c:770:2
#3 sync_keyzone lib/dns/zone.c:4586:2
#4 dns_zone_synckeyzone lib/dns/zone.c:4635:11
#5 mkey_refresh bin/named/server.c:15423:2
#6 named_server_mkeys bin/named/server.c:15727:4
#7 named_control_docommand bin/named/control.c:236:12
#8 control_command bin/named/controlconf.c:365:17
#9 dispatch lib/isc/task.c:1152:7
#10 run lib/isc/task.c:1344:2
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) in pthread_rwlock_rdlock
(cherry picked from commit 9e5f83c499
2020-09-17 18:24:06 +10:00
Tinderbox User
a4f73cfe8a
prep 9.16.7
2020-09-16 22:50:38 +02:00
Evan Hunt
df698d73f4
update all copyright headers to eliminate the typo
2020-09-14 16:50:58 -07:00
Mark Andrews
947bc2594b
Only test node->data if we care about whether data is present or not.
...
WARNING: ThreadSanitizer: data race (pid=28788)
Write of size 8 at 0x7b200002e060 by thread T1 (mutexes: write M2947):
#0 add32 /builds/isc-projects/bind9/lib/dns/rbtdb.c:6638:18 (libdns.so.1110+0xe7843)
#1 addrdataset /builds/isc-projects/bind9/lib/dns/rbtdb.c:6975:12 (libdns.so.1110+0xe4185)
#2 dns_db_addrdataset /builds/isc-projects/bind9/lib/dns/db.c:783:10 (libdns.so.1110+0x650ee)
#3 validated /builds/isc-projects/bind9/lib/dns/resolver.c:5140:11 (libdns.so.1110+0x1909f7)
#4 dispatch /builds/isc-projects/bind9/lib/isc/task.c:1157:7 (libisc.so.1107+0x507f5)
#5 run /builds/isc-projects/bind9/lib/isc/task.c:1331:2 (libisc.so.1107+0x4d749)
Previous read of size 8 at 0x7b200002e060 by thread T5 (mutexes: write M521146194917735760):
#0 dns_rbt_findnode /builds/isc-projects/bind9/lib/dns/rbt.c:1708:9 (libdns.so.1110+0xd910d)
#1 cache_find /builds/isc-projects/bind9/lib/dns/rbtdb.c:5098:11 (libdns.so.1110+0xe188e)
#2 dns_db_find /builds/isc-projects/bind9/lib/dns/db.c:554:11 (libdns.so.1110+0x642bb)
#3 dns_view_find2 /builds/isc-projects/bind9/lib/dns/view.c:1068:11 (libdns.so.1110+0x1cc2c4)
#4 dbfind_name /builds/isc-projects/bind9/lib/dns/adb.c:3714:11 (libdns.so.1110+0x46a4b)
#5 dns_adb_createfind2 /builds/isc-projects/bind9/lib/dns/adb.c:3133:12 (libdns.so.1110+0x45278)
#6 findname /builds/isc-projects/bind9/lib/dns/resolver.c:3166:11 (libdns.so.1110+0x1827f0)
#7 fctx_getaddresses /builds/isc-projects/bind9/lib/dns/resolver.c:3462:3 (libdns.so.1110+0x18032d)
#8 fctx_try /builds/isc-projects/bind9/lib/dns/resolver.c:3819:12 (libdns.so.1110+0x17e174)
#9 fctx_start /builds/isc-projects/bind9/lib/dns/resolver.c:4219:4 (libdns.so.1110+0x1787a3)
#10 dispatch /builds/isc-projects/bind9/lib/isc/task.c:1157:7 (libisc.so.1107+0x507f5)
#11 run /builds/isc-projects/bind9/lib/isc/task.c:1331:2 (libisc.so.1107+0x4d749)
(cherry picked from commit 71ef3a8038
2020-09-09 16:22:39 +10:00
Mark Andrews
f6ba3ec731
Address lock-order-inversion
...
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=12714)
Cycle in lock order graph: M100252 (0x7b7c00010a08) => M1171 (0x7b7400000dc8) => M100252
Mutex M1171 acquired here while holding mutex M100252 in thread T1:
#0 pthread_mutex_lock <null> (delv+0x4483a6)
#1 dns_resolver_createfetch3 /builds/isc-projects/bind9/lib/dns/resolver.c:9585:2 (libdns.so.1110+0x1769fd)
#2 dns_resolver_createfetch /builds/isc-projects/bind9/lib/dns/resolver.c:9504:10 (libdns.so.1110+0x174e17)
#3 create_fetch /builds/isc-projects/bind9/lib/dns/validator.c:1156:10 (libdns.so.1110+0x1c1e5f)
#4 validatezonekey /builds/isc-projects/bind9/lib/dns/validator.c:2124:13 (libdns.so.1110+0x1c3b6d)
#5 start_positive_validation /builds/isc-projects/bind9/lib/dns/validator.c:2301:10 (libdns.so.1110+0x1bfde9)
#6 validator_start /builds/isc-projects/bind9/lib/dns/validator.c:3647:12 (libdns.so.1110+0x1bef62)
#7 dispatch /builds/isc-projects/bind9/lib/isc/task.c:1157:7 (libisc.so.1107+0x507d5)
#8 run /builds/isc-projects/bind9/lib/isc/task.c:1331:2 (libisc.so.1107+0x4d729)
Mutex M100252 previously acquired by the same thread here:
#0 pthread_mutex_lock <null> (delv+0x4483a6)
#1 validator_start /builds/isc-projects/bind9/lib/dns/validator.c:3628:2 (libdns.so.1110+0x1bee31)
#2 dispatch /builds/isc-projects/bind9/lib/isc/task.c:1157:7 (libisc.so.1107+0x507d5)
#3 run /builds/isc-projects/bind9/lib/isc/task.c:1331:2 (libisc.so.1107+0x4d729)
Mutex M100252 acquired here while holding mutex M1171 in thread T1:
#0 pthread_mutex_lock <null> (delv+0x4483a6)
#1 dns_validator_destroy /builds/isc-projects/bind9/lib/dns/validator.c:3912:2 (libdns.so.1110+0x1bf788)
#2 validated /builds/isc-projects/bind9/lib/dns/resolver.c:4916:2 (libdns.so.1110+0x18fdfd)
#3 dispatch /builds/isc-projects/bind9/lib/isc/task.c:1157:7 (libisc.so.1107+0x507d5)
#4 run /builds/isc-projects/bind9/lib/isc/task.c:1331:2 (libisc.so.1107+0x4d729)
Mutex M1171 previously acquired by the same thread here:
#0 pthread_mutex_lock <null> (delv+0x4483a6)
#1 validated /builds/isc-projects/bind9/lib/dns/resolver.c:4907:2 (libdns.so.1110+0x18fc3d)
#2 dispatch /builds/isc-projects/bind9/lib/isc/task.c:1157:7 (libisc.so.1107+0x507d5)
#3 run /builds/isc-projects/bind9/lib/isc/task.c:1331:2 (libisc.so.1107+0x4d729)
Thread T1 'isc-worker0000' (tid=12729, running) created by main thread at:
#0 pthread_create <null> (delv+0x42afdb)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/pthreads/thread.c:60:8 (libisc.so.1107+0x726d8)
#2 isc__taskmgr_create /builds/isc-projects/bind9/lib/isc/task.c:1468:7 (libisc.so.1107+0x4d635)
#3 isc_taskmgr_createinctx /builds/isc-projects/bind9/lib/isc/task.c:2091:11 (libisc.so.1107+0x4f4ac)
#4 main /builds/isc-projects/bind9/bin/delv/delv.c:1639:2 (delv+0x4b7f96)
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) (/builds/isc-projects/bind9/bin/delv/.libs/delv+0x4483a6) in pthread_mutex_lock
(cherry picked from commit 992a79a14b
2020-09-09 16:22:39 +10:00
Mark Andrews
5d469f2498
Address lock-order-inversion
...
Obtain references to view->redirect and view->managed_keys then
release view->lock so dns_zone_setviewcommit and dns_zone_setviewrevert
can obtain the view->lock while holding zone->lock.
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=9132)
Cycle in lock order graph: M987831431424375936 (0x000000000000) => M1012319771577875480 (0x000000000000) => M987831431424375936
Mutex M1012319771577875480 acquired here while holding mutex M987831431424375936 in thread T2:
#0 pthread_mutex_lock <null> (named+0x4642a6)
#1 dns_zone_setviewcommit /builds/isc-projects/bind9/lib/dns/zone.c:1571:2 (libdns.so.1110+0x1d74eb)
#2 dns_view_setviewcommit /builds/isc-projects/bind9/lib/dns/view.c:2388:3 (libdns.so.1110+0x1cfe29)
#3 load_configuration /builds/isc-projects/bind9/bin/named/./server.c:8188:3 (named+0x51eadd)
#4 loadconfig /builds/isc-projects/bind9/bin/named/./server.c:9438:11 (named+0x510c66)
#5 ns_server_reconfigcommand /builds/isc-projects/bind9/bin/named/./server.c:9773:2 (named+0x510b41)
#6 ns_control_docommand /builds/isc-projects/bind9/bin/named/control.c:243:12 (named+0x4e451a)
#7 control_recvmessage /builds/isc-projects/bind9/bin/named/controlconf.c:465:13 (named+0x4e9056)
#8 dispatch /builds/isc-projects/bind9/lib/isc/task.c:1157:7 (libisc.so.1107+0x507d5)
#9 run /builds/isc-projects/bind9/lib/isc/task.c:1331:2 (libisc.so.1107+0x4d729)
Mutex M987831431424375936 previously acquired by the same thread here:
#0 pthread_mutex_lock <null> (named+0x4642a6)
#1 dns_view_setviewcommit /builds/isc-projects/bind9/lib/dns/view.c:2382:2 (libdns.so.1110+0x1cfde7)
#2 load_configuration /builds/isc-projects/bind9/bin/named/./server.c:8188:3 (named+0x51eadd)
#3 loadconfig /builds/isc-projects/bind9/bin/named/./server.c:9438:11 (named+0x510c66)
#4 ns_server_reconfigcommand /builds/isc-projects/bind9/bin/named/./server.c:9773:2 (named+0x510b41)
#5 ns_control_docommand /builds/isc-projects/bind9/bin/named/control.c:243:12 (named+0x4e451a)
#6 control_recvmessage /builds/isc-projects/bind9/bin/named/controlconf.c:465:13 (named+0x4e9056)
#7 dispatch /builds/isc-projects/bind9/lib/isc/task.c:1157:7 (libisc.so.1107+0x507d5)
#8 run /builds/isc-projects/bind9/lib/isc/task.c:1331:2 (libisc.so.1107+0x4d729)
Mutex M987831431424375936 acquired here while holding mutex M1012319771577875480 in thread T7:
#0 pthread_mutex_lock <null> (named+0x4642a6)
#1 dns_view_findzonecut2 /builds/isc-projects/bind9/lib/dns/view.c:1300:2 (libdns.so.1110+0x1cc93a)
#2 dns_view_findzonecut /builds/isc-projects/bind9/lib/dns/view.c:1261:9 (libdns.so.1110+0x1cc864)
#3 fctx_create /builds/isc-projects/bind9/lib/dns/resolver.c:4459:13 (libdns.so.1110+0x1779d3)
#4 dns_resolver_createfetch3 /builds/isc-projects/bind9/lib/dns/resolver.c:9628:12 (libdns.so.1110+0x176cb6)
#5 dns_resolver_createfetch /builds/isc-projects/bind9/lib/dns/resolver.c:9504:10 (libdns.so.1110+0x174e17)
#6 zone_refreshkeys /builds/isc-projects/bind9/lib/dns/zone.c:10061:12 (libdns.so.1110+0x2055a5)
#7 zone_maintenance /builds/isc-projects/bind9/lib/dns/zone.c:10274:5 (libdns.so.1110+0x203a78)
#8 zone_timer /builds/isc-projects/bind9/lib/dns/zone.c:13106:2 (libdns.so.1110+0x1e815a)
#9 dispatch /builds/isc-projects/bind9/lib/isc/task.c:1157:7 (libisc.so.1107+0x507d5)
#10 run /builds/isc-projects/bind9/lib/isc/task.c:1331:2 (libisc.so.1107+0x4d729)
Mutex M1012319771577875480 previously acquired by the same thread here:
#0 pthread_mutex_lock <null> (named+0x4642a6)
#1 zone_refreshkeys /builds/isc-projects/bind9/lib/dns/zone.c:9951:2 (libdns.so.1110+0x204dc3)
#2 zone_maintenance /builds/isc-projects/bind9/lib/dns/zone.c:10274:5 (libdns.so.1110+0x203a78)
#3 zone_timer /builds/isc-projects/bind9/lib/dns/zone.c:13106:2 (libdns.so.1110+0x1e815a)
#4 dispatch /builds/isc-projects/bind9/lib/isc/task.c:1157:7 (libisc.so.1107+0x507d5)
#5 run /builds/isc-projects/bind9/lib/isc/task.c:1331:2 (libisc.so.1107+0x4d729)
Thread T2 'isc-worker0001' (tid=9163, running) created by main thread at:
#0 pthread_create <null> (named+0x446edb)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/pthreads/thread.c:60:8 (libisc.so.1107+0x726d8)
#2 isc__taskmgr_create /builds/isc-projects/bind9/lib/isc/task.c:1468:7 (libisc.so.1107+0x4d635)
#3 isc_taskmgr_create /builds/isc-projects/bind9/lib/isc/task.c:2109:11 (libisc.so.1107+0x4f587)
#4 create_managers /builds/isc-projects/bind9/bin/named/./main.c:886:11 (named+0x4f1a97)
#5 setup /builds/isc-projects/bind9/bin/named/./main.c:1305:11 (named+0x4f05ee)
#6 main /builds/isc-projects/bind9/bin/named/./main.c:1556:2 (named+0x4ef12d)
Thread T7 'isc-worker0006' (tid=9168, running) created by main thread at:
#0 pthread_create <null> (named+0x446edb)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/pthreads/thread.c:60:8 (libisc.so.1107+0x726d8)
#2 isc__taskmgr_create /builds/isc-projects/bind9/lib/isc/task.c:1468:7 (libisc.so.1107+0x4d635)
#3 isc_taskmgr_create /builds/isc-projects/bind9/lib/isc/task.c:2109:11 (libisc.so.1107+0x4f587)
#4 create_managers /builds/isc-projects/bind9/bin/named/./main.c:886:11 (named+0x4f1a97)
#5 setup /builds/isc-projects/bind9/bin/named/./main.c:1305:11 (named+0x4f05ee)
#6 main /builds/isc-projects/bind9/bin/named/./main.c:1556:2 (named+0x4ef12d)
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) (/builds/isc-projects/bind9/bin/named/.libs/named+0x4642a6) in pthread_mutex_lock
(cherry picked from commit cdcfde9e65
2020-09-09 16:22:39 +10:00
Ondřej Surý
56d2cf6f1e
Print diagnostics on dns_name_issubdomain() failure in fctx_create()
...
Log diagnostic message when dns_name_issubdomain() in the fctx_create()
when the resolver is qname minimizing and forwarding at the same time.
(cherry picked from commit 0a22024c27
2020-09-02 18:29:01 +02:00
Diego Fronza
eb9d8e9e10
Fix resolution of unusual ip6.arpa names
...
Before this commit, BIND was unable to resolve ip6.arpa names like
the one reported in issue #1847 when using query minimization.
As reported in the issue, an attempt to resolve a name like
'rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa'
using default settings would fail.
The reason was that query minimization algorithm in 'fctx_minimize_qname'
would divide any ip6.arpa names in increasing number of labels,
7,11, ... up to 35, thus limiting the destination name (minimized) to a number
of 35 labels.
In case the last query minimization attempt (with 35 labels) would fail with
NXDOMAIN, BIND would attempt the query mininimization again with the exact
same QNAME, limited on the 35 labels, and that in turn would fail again.
This fix avoids this fail loop by considering the extra labels that may appear
in the leftmost part of an ip6.arpa name, those after the IPv6 part.
(cherry picked from commit 230d79c191
2020-09-02 16:52:39 +02:00
Matthijs Mekking
4a7f87aa89
Log when CDS/CDNSKEY is published in zone.
...
Log when named decides to add a CDS/CDNSKEY record to the zone. Now
you understand how the bug was found that was fixed in the previous
commits.
(cherry picked from commit f9ef5120c1
2020-09-02 14:59:20 +02:00
Matthijs Mekking
6405b04477
Fix CDS (non-)publication
...
The CDS/CDNSKEY record will be published when the DS is in the
rumoured state. However, with the introduction of the rndc '-checkds'
command, the logic in the keymgr was changed to prevent the DS
state to go in RUMOURED unless the specific command was given. Hence,
the CDS was never published before it was seen in the parent.
Initially I thought this was a policy approval rule, however it is
actually a DNSSEC timing rule. Remove the restriction from
'keymgr_policy_approval' and update the 'keymgr_transition_time'
function. When looking to move the DS state to OMNIPRESENT it will
no longer calculate the state from its last change, but from when
the DS was seen in the parent, "DS Publish". If the time was not set,
default to next key event of an hour.
Similarly for moving the DS state to HIDDEN, the time to wait will
be derived from the "DS Delete" time, not from when the DS state
last changed.
(cherry picked from commit c8205bfa0e
2020-09-02 14:59:20 +02:00
Mark Andrews
489b99b65c
remove unused variable sock
...
(cherry picked from commit b1c424ddf3
2020-09-02 08:41:11 +10:00
