Description

dns_int_match_ip is broken on 5.3.0 and above

Troubleshooting

Reproduction

Try this dialplan:

if (dns_int_match_ip('dns.google', '8.8.8.8')) {
   xlog("L_INFO", "OK dns-ip match with dns_int_match_ip");
} else {
   xlog("L_ERR", "FAIL dns-ip match with dns_int_match_ip");
}

if (dns_int_match_ip('100.100.100.100', '8.8.8.8')) {
   xlog("L_ERR", "FAIL dns_int_match_ip on 2 ip's");
} else {
   xlog("L_INFO", "OK dns_int_match_ip on 2 ip's");
}

On 5.2 releases, both checks succeed. On 5.3 and up, both fail.

Debugging Data

I've traced down the problem to str2ip.

In 5.2, this is a static inline function defined in the header file resolve.h. Therefore, the returned ip structure is allocated once per compilation unit - ie. ipops_mod.c and dns_cache.c both have their own versions of the variable.

Since fb75e90 (5.3 and up) this function is defined in it's own compilation unit (resolve.c) and therefore shared by all callers.

See: https://stackoverflow.com/questions/185624/static-variables-in-an-inlined-function

Log Messages

n/a

SIP Traffic

n/a

Possible Solutions

• Have ki_dns_sys_match_ip make a local copy of the return value of str2ip
• Move str2ip back to a header file
• Refactor str2ip to take a pointer to an output struct

Additional Information

In 5.3, this is what happens:

# - ki_dns_int_match_ip will call str2ip on 8.8.8.8, filling the static variable
# - resolvehost will call dns_a_get_he, which calls str2ip on dns.google.com, zeroing out the static variable
# - (dns_cache_do_request will call str2ip on dns.google.com, zeroing out the static variable again)
# - resolvehost queries DNS
# - the resolved IP's will be compared to the zero'd out struct
dns_int_match_ip('dns.google', '8.8.8.8') == false

# - ki_dns_int_match_ip will call str2ip on 8.8.8.8, filling the static variable
# - resolvehost will call dns_a_get_he, which calls str2ip on 100.100.100.100, overwriting the static variable
# - the static variable will be compared to itself
dns_int_match_ip('100.100.100.100', '8.8.8.8') == true

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.