Bug 20261: Treat AF_UNIX addresses as equal when comparing them.

This is a kludge to deal with the fact that `tor_addr_t` doesn't contain
`sun_path`.  This currently ONLY happens when circuit isolation is being
checked, for an isolation mode that is force disabled anyway, so the
kludge is "ugly but adequate", but realistically, making `tor_addr_t`
and the AF_UNIX SocksPort code do the right thing is probably the better
option.

1 files changed, 16 insertions, 0 deletions

diff --git a/src/common/address.c b/src/common/address.c
index 6799dd6c56..dd2164eacf 100644
--- a/src/common/address.c
+++ b/src/common/address.c
@@ -1041,6 +1041,10 @@ tor_addr_copy_tight(tor_addr_t *dest, const tor_addr_t *src)
  * Different address families (IPv4 vs IPv6) are always considered unequal if
  * <b>how</b> is CMP_EXACT; otherwise, IPv6-mapped IPv4 addresses are
  * considered equivalent to their IPv4 equivalents.
+ *
+ * As a special case, all AF_UNIX addresses are always considered equal
+ * since tor_addr_t currently does not contain the information required to
+ * make the comparison.
  */
 int
 tor_addr_compare(const tor_addr_t *addr1, const tor_addr_t *addr2,
@@ -1114,6 +1118,18 @@ tor_addr_compare_masked(const tor_addr_t *addr1, const tor_addr_t *addr2,
           return 0;
         }
       }
+      case AF_UNIX:
+        /* HACKHACKHACKHACKHACK:
+         * tor_addr_t doesn't contain a copy of sun_path, so it's not
+         * possible to comapre this at all.
+         *
+         * Since the only time we currently actually should be comparing
+         * 2 AF_UNIX addresses is when dealing with ISO_CLIENTADDR (which
+         * is diesabled for AF_UNIX SocksPorts anyway), this just returns 0.
+         *
+         * See: #20261.
+         */
+        return 0;
       default:
         /* LCOV_EXCL_START */
         tor_fragile_assert();