Xray-core icon indicating copy to clipboard operation
Xray-core copied to clipboard

panic: Calling IP() on a DomainAddress

Open maskedeken opened this issue 4 years ago • 10 comments

在往buf.Buffer的UDP属性赋值的时候,创建 &net.UDPAddr{ IP: addr.IP(), Port: int(port.Value()), }

但这里的addr是从addrParser.ReadAddressPort()而来,这里的addr有可能是域名,如果直接调用addr.IP(),会直接panic

func (domainAddress) IP() net.IP { panic("Calling IP() on a DomainAddress.") }

maskedeken avatar Dec 30 '20 06:12 maskedeken

两天前的提交已经修复 https://github.com/XTLS/Xray-core/commit/13ad3fddf6f7ff01fe9541b6c9f2dca6f7f87e4b

(不过最新的 commit 有问题,等下会 force

RPRX avatar Dec 30 '20 06:12 RPRX

怎么解决循环引用的问题?

maskedeken avatar Dec 30 '20 07:12 maskedeken

怎么解决循环引用的问题?

https://github.com/XTLS/Xray-core/commit/6bcac6cb1016295a0722015ec853ece135766cc3

RPRX avatar Dec 30 '20 07:12 RPRX

如果发现存在其它问题,也请直接反馈

比如目前发现任意门 TPROXY 那里不能缓存 conns,只能发一个包就 close,否则行为会异常,等下打算看看把 dial 改为 listen 的表现

RPRX avatar Dec 30 '20 14:12 RPRX

问题修复了吗,我用最新版碰到了相同的问题 我想大概是使用TPROXY转发UDP流量导致,使用tun2socks转发不会出现这类问题。

z719893361 avatar Aug 30 '22 05:08 z719893361

I encountered this issue just now on xray 1.8.10

unfortunately i have nothing useful to reproduce it with. the server config has been running fine for a very long time before then, so i suspect it is somehow triggered by traffic and not the config itself. but i also don't know which protocol.

stacktrace
panic: Calling IP() on a DomainAddress.

goroutine 10315396 [running]:
github.com/xtls/xray-core/common/net.domainAddress.IP(...)
   github.com/xtls/xray-core/common/net/address.go:164
github.com/xtls/xray-core/features/routing/session.(*Context).GetTargetIPs(0xc00cfb1290)
   github.com/xtls/xray-core/features/routing/session/context.go:54 +0x5f
github.com/xtls/xray-core/app/router.(*MultiGeoIPMatcher).Apply(0xc0003bc4e0, {0x1549850?, 0xc00cfb1290?})
   github.com/xtls/xray-core/app/router/condition.go:142 +0x3e
github.com/xtls/xray-core/app/router.(*ConditionChan).Apply(0x8?, {0x1549850, 0xc00cfb1290})
   github.com/xtls/xray-core/app/router/condition.go:31 +0x5c
github.com/xtls/xray-core/app/router.(*Rule).Apply(...)
   github.com/xtls/xray-core/app/router/config.go:28
github.com/xtls/xray-core/app/router.(*Router).pickRouteInternal(0xc0003a1260, {0x1549850, 0xc00cfb1290})
   github.com/xtls/xray-core/app/router/router.go:195 +0x176
github.com/xtls/xray-core/app/router.(*Router).PickRoute(0x15402b8?, {0x1549850?, 0xc00cfb1290?})
   github.com/xtls/xray-core/app/router/router.go:83 +0x25
github.com/xtls/xray-core/app/dispatcher.(*DefaultDispatcher).routedDispatch(0xc00039d8c0, {0x15402b8, 0xc009bfa570}, 0xc00bdaa360, {{0x1540440, 0xc00b6dc204}, 0x1bb, 0x2})
   github.com/xtls/xray-core/app/dispatcher/default.go:403 +0x2e2
github.com/xtls/xray-core/app/dispatcher.(*DefaultDispatcher).Dispatch.func1()
   github.com/xtls/xray-core/app/dispatcher/default.go:266 +0x3f9
created by github.com/xtls/xray-core/app/dispatcher.(*DefaultDispatcher).Dispatch in goroutine 10315389
   github.com/xtls/xray-core/app/dispatcher/default.go:239 +0x40b
config (users, wireguard credentials and http paths redacted)
{
  "inbounds": [
    {
      "listen": "0.0.0.0",
      "port": 42007,
      "protocol": "socks",
      "settings": {
        "auth": "password",
        "accounts": [
        ],
        "udp": true,
        "userLevel": 8
      },
      "sniffing": {
        "destOverride": [
          "http",
          "tls"
        ],
        "enabled": true
      },
      "tag": "socks"
    },
    {
      "port": 42003,
      "listen": "0.0.0.0",
      "protocol": "vmess",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      },
      "settings": {
        "clients": [
        ]
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
          "path": "/xxx"
        }
      }
    },
    {
      "port": 42005,
      "listen": "0.0.0.0",
      "protocol": "vmess",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      },
      "settings": {
        "clients": [
        ]
      },
      "streamSettings": {
        "network": "grpc",
        "grpcSettings": {
          "serviceName": "xxx"
        }
      }
    },
    {
      "port": 42006,
      "listen": "0.0.0.0",
      "protocol": "vmess",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      },
      "settings": {
        "clients": [
        ]
      },
      "streamSettings": {
        "network": "httpupgrade",
        "httpUpgradeSettings": {
          "path": "/xxx"
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "wireguard",
    },
    {
      "protocol": "blackhole",
      "settings": {},
      "tag": "block"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "outboundTag": "block",
        "protocol": [
          "bittorrent"
        ]
      },
      {
        "type": "field",
        "outboundTag": "block",
        "ip": [
          "0.0.0.0/8",
          "10.0.0.0/8",
          "100.64.0.0/10",
          "127.0.0.0/8",
          "169.254.0.0/16",
          "172.16.0.0/12",
          "192.0.0.0/24",
          "192.0.2.0/24",
          "192.88.99.0/24",
          "192.168.0.0/16",
          "198.18.0.0/15",
          "198.51.100.0/24",
          "203.0.113.0/24",
          "224.0.0.0/4",
          "233.252.0.0/24",
          "240.0.0.0/4",
          "255.255.255.255/32"
        ]
      }
    ]
  },
  "log": {
    "access": "none",
    "error": "",
    "loglevel": "error"
  }
}

mmmray avatar Apr 24 '24 00:04 mmmray

It occurs with 1.8.13 as well. Stacktrace is the same.

Is it reasonable to think the broken address comes from a specific inbound? I can try to remove inbounds from production (or rather, move them to a secondary xray container) until the problem stops occurring, but would like to know if it's worth the effort.

currently the issue only happens 2-3 times per day, so it's kind of fine with autorestart.

mmmray avatar May 26 '24 15:05 mmmray

Also had this a few times on one server. Can you by any chance have any outbound with ForceIP?

I didn't checked the code but I didn't see this error anymore when I removed plain ForceIP from outbound (ForceIPv4v6 & ForceIPv6v4 is ok for me)

somebodywashere avatar May 26 '24 21:05 somebodywashere

i posted my full config above, no I don't use any variant of ForceIP.

mmmray avatar May 26 '24 21:05 mmmray

i posted my full config above, no I don't use any variant of ForceIP.

Oh, sorry, didn't pay enough attention. Now I see. That's strange than.

If I encounter that once more I'll get back with additional info.

somebodywashere avatar May 26 '24 22:05 somebodywashere

Hi @RPRX @yuhan6665 @mmmray , on core 1.8.23, this log appears and stop core .(go1.22.5 linux/amd64)

2024/08/13 21:08:29 DEBUG - XRAY: 2334503 2024/08/13 21:08:29 DEBUG - XRAY: {0x156c6d0?, 0xc00977fc98?}) 2024/08/13 21:08:29 DEBUG - XRAY: github.com/xtls/xray-core/common/net.domainAddress.IP(...) 2024/08/13 21:08:29 DEBUG - XRAY: panic: Calling IP() on a DomainAddress.

what is problem ?

ssmetall avatar Aug 13 '24 21:08 ssmetall

by the way, I patched the panic in question to print out the inner domain address, and it shows all kinds of normal hosts/domain names. Therefore this is not the same bug as #3628, where things such as DomainAddress("192.168.0.1") were constructed.

mmmray avatar Aug 16 '24 20:08 mmmray

Some update here. I patched xray with this patch on top of 1.8.23:

diff --git a/features/routing/session/context.go b/features/routing/session/context.go
index 3c9764b..5153b12 100644
--- a/features/routing/session/context.go
+++ b/features/routing/session/context.go
@@ -2,6 +2,8 @@ package session

 import (
        "context"
+       "time"
+       "fmt"

        "github.com/xtls/xray-core/common/net"
        "github.com/xtls/xray-core/common/session"
@@ -50,8 +52,15 @@ func (ctx *Context) GetTargetIPs() []net.IP {
                return nil
        }

-       if ctx.Outbound.Target.Address.Family().IsIP() {
-               return []net.IP{ctx.Outbound.Target.Address.IP()}
+       addr := ctx.Outbound.Target.Address
+
+       if addr.Family().IsIP() {
+               time.Sleep(time.Millisecond)
+               addr2 := ctx.Outbound.Target.Address
+               if !addr2.Family().IsIP() {
+                       fmt.Println("XDEBUG before: ", addr, "after: ", addr2)
+               }
+               return []net.IP{addr.IP()}
        }

        return nil

And am getting this output after a while:

XDEBUG before:  1.1.1.1 after:  mqtt-mini.facebook.com
XDEBUG before:  149.154.167.41 after:  scontent-fra3-2.cdninstagram.com
XDEBUG before:  157.240.253.61 after:  mtalk.google.com
XDEBUG before:  1.1.1.1 after:  mtalk.google.com
XDEBUG before:  157.240.253.61 after:  mtalk.google.com
XDEBUG before:  149.154.167.223 after:  www.google.com

I think it means that the ctx (or outbound, or target, ..) is being modified while GetTargetIPs is being called, and that's why it's crashing.

Note that the IP addresses stand in no relation to the hostnames at all, 1.1.1.1 certainly doesn't belong to google.

mmmray avatar Aug 22 '24 14:08 mmmray

Hi @RPRX @yuhan6665 @mmmray , on core 1.8.23, this log appears and stop core .(go1.22.5 linux/amd64)

2024/08/13 21:08:29 DEBUG - XRAY: 2334503 2024/08/13 21:08:29 DEBUG - XRAY: {0x156c6d0?, 0xc00977fc98?}) 2024/08/13 21:08:29 DEBUG - XRAY: github.com/xtls/xray-core/common/net.domainAddress.IP(...) 2024/08/13 21:08:29 DEBUG - XRAY: panic: Calling IP() on a DomainAddress.

what is problem ?

my problem sloved with this options in 1.8.23

protocol": "freedom", "settings": { "domainStrategy": "ForceIPv4

and

routing": { "domainStrategy": "IPIfNonMatch", "rules": [

The problem was in asIs for freedom and routing

ssmetall avatar Aug 22 '24 14:08 ssmetall

We should fix crash even if you configured wrong, please try to post your stacktace

yuhan6665 avatar Aug 22 '24 14:08 yuhan6665

I applied those config changes and got the same crash almost immediately

panic: Calling IP() on a DomainAddress.

goroutine 123018 [running]:
github.com/xtls/xray-core/common/net.domainAddress.IP(...)
    github.com/xtls/xray-core/common/net/address.go:172
github.com/xtls/xray-core/features/routing/session.(*Context).GetTargetIPs(0xc004175428)
    github.com/xtls/xray-core/features/routing/session/context.go:54 +0x5f
github.com/xtls/xray-core/app/router.(*MultiGeoIPMatcher).Apply(0xc0003a63e0, {0x156c770?, 0xc004175428?})
    github.com/xtls/xray-core/app/router/condition.go:143 +0x3e
github.com/xtls/xray-core/app/router.(*ConditionChan).Apply(0x495c9d?, {0x156c770, 0xc004175428})
    github.com/xtls/xray-core/app/router/condition.go:32 +0x5c
github.com/xtls/xray-core/app/router.(*Rule).Apply(...)
    github.com/xtls/xray-core/app/router/config.go:30
github.com/xtls/xray-core/app/router.(*Router).pickRouteInternal(0xc000367a40, {0x156c770, 0xc004175428})
    github.com/xtls/xray-core/app/router/router.go:196 +0x176
github.com/xtls/xray-core/app/router.(*Router).PickRoute(0x1562810?, {0x156c770?, 0xc004175428?})
    github.com/xtls/xray-core/app/router/router.go:84 +0x25
github.com/xtls/xray-core/app/dispatcher.(*DefaultDispatcher).routedDispatch(0xc000398fc0, {0x1562810, 0xc0050cd350}, 0xc00418dea0, {{0x15625a8, 0xc005974c10}, 0x1bb, 0x2})
    github.com/xtls/xray-core/app/dispatcher/default.go:420 +0x307
created by github.com/xtls/xray-core/app/dispatcher.(*DefaultDispatcher).Dispatch in goroutine 123015
    github.com/xtls/xray-core/app/dispatcher/default.go:252 +0x56c

I think I know though where the race condition happens:

https://github.com/XTLS/Xray-core/blob/41d03d1856a5b16521610792601a20fb1195418e/app/dispatcher/default.go#L242

this line essentially mutates outbound while other goroutines may access it:

  1. call Dispatch twice with the same context
  2. call 1 mutates outbound.Target to be an IPAddress and spawns goroutine 1
  3. goroutine 1 goes to IsIP check in GetTargetIPs, and it returns true
  4. call 2 mutates outbound.Target to be a DomainAddress
  5. goroutine 1 calls IP() and gets a crash

mmmray avatar Aug 22 '24 15:08 mmmray

why it would call dispatch more than once?

yuhan6665 avatar Aug 22 '24 15:08 yuhan6665

@yuhan6665 it's two completely unrelated connections going through the same outbound.

mmmray avatar Aug 22 '24 15:08 mmmray

That should be different contexts though

it's two completely unrelated connections going through the same outbound.

yuhan6665 avatar Aug 22 '24 15:08 yuhan6665

it's possible the contexts are different but pointing to the same outbound object. I guess this sounds illogical but the signs point in that direction. Otherwise, how can it be that I'm observing mutations from 1.1.1.1 to some google domain from within GetTargetIPs?

mmmray avatar Aug 22 '24 15:08 mmmray