Maintained by: NLnet Labs

[Unbound-users] questions about mesh_make_new_space() function

Matthew Lee
Thu Oct 20 09:50:05 CEST 2011


Hi,

I don't know if it's appropriate to discuss specific code here, but
mesh_make_new_space() maybe is at risk under particular conditions.

when the mesh_state queue is full and new query comes in, one mesh_state
will be kicked out which is happened in mesh_make_new_space() function, and
call mesh_state_delete() function. mesh_state_delete() function will
eventually call iter_clear(), iter_clear() will delete the outnet query of
this mesh_state which is in function serviced_delete().

serviced_delete() call outnet_send_wait_udp() which will re-send some
queries failed to send out last time, in these code
outnet_send_wait_udp(struct outside_network* outnet)
{
...
if(!randomize_and_send_udp(outnet, pend, outnet->udp_buff,
pend->timeout)) {
/* callback error on pending */
fptr_ok(fptr_whitelist_pending_udp(pend->cb));
(void)(*pend->cb)(outnet->unused_fds->cp, pend->cb_arg,
NETEVENT_CLOSED, NULL);
pending_delete(outnet, pend);
}
}

if randomize_and_send_udp() fail again, then pend->cb() will be called and
will eventually go to mesh_run() function, and in iterator module it
probably return SERVFAIL immediately while it still take control of the
thread, maybe like these code in processQueryTargets().
if(!target) {
if(iq->num_target_queries==0 && iq->num_current_queries==0) {
if(delegpt_count_missing_targets(iq->dp) > 0) {
int qs = 0;
verbose(VERB_ALGO, "querying for next "
"missing target");
if(!query_for_targets(qstate, iq, ie, id,
1, &qs)) {
return error_response(qstate, id,
LDNS_RCODE_SERVFAIL);

or these in  processQueryTargets()
                 if(iq->num_target_queries == 0) {
return processLastResort(qstate, iq, ie, id);
}

then error_response() use c->buffer to send packet, and the buffer is used
by new query at the same time. after mesh_state_delete(), new query's qname
will point to wrong packet, but qname_len is right.

I'd say it's not that easy to happen in online environment, but still
possible in small probability.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20111020/8f223de3/attachment.html>