TUN模式下出现panic: runtime error: slice bounds out of range #3303
Comments
|
我此前似乎遇到过 #2886（看那个 PR 修改前的评论）。这个是 Chromium quiche 的所谓 Chaos Protection 导致的问题，目前的 sniffer 不能处理 QUIC crypto frame 被拆分到多个 QUIC Initial packet（此时 crypto frame offset + crypto frame length 会超出包长度）的情况。但是 sniffer 只处理序号为 0 或 1 的 QUIC Initial packet，而当时的 Chrome 仅在序号为 2 的 QUIC Initial packet 会有此种情况，所以只会导致嗅探失败而不会 panic。所以要么你用的 v2ray 经过修改了，要么是现在的 Chromium 发送 QUIC Initial packet 的方式改变了，或者是有人恶意构造会导致 panic 的流量。建议把抓包结果发出来看看。 |
非常感谢您提供的信息，我认为您描述的问题正是我遇到的。 我在MAC上复现了这个问题并使用wireshark进行抓包。
wireshark中似乎同时在此时间点有initial PKN 为1-3的情况。（注意V2Ray使用了fakeDNS，日志中198.18.1.X为fakeDNS的网段）
关于您提到的v2ray经过修改或有人恶意构造的问题，当前环境是自行从github下载搭建的，也没有其他用户使用，应当可以排除。 请帮忙确认，看是否能够解决此问题。 Thanks |
|
补充一下，如下Offset+Length（1844+426）确实与panic中的2270对应。 4456 2025-02-07 20:46:25.337152 10.0.0.61 198.18.1.11 QUIC 1292 Initial, DCID=261dd0fa3d804cd5, PKN: 1, PADDING, CRYPTO, PING, PADDING, CRYPTO, CRYPTO, PING, CRYPTO, PING, PADDING, CRYPTO, PADDING, PING, PING, PING, PING, CRYPTO, CRYPTO, CRYPTO, CRYPTO, PING, PING panic: runtime error: slice bounds out of range [:2270] with capacity 2048 |
|
按照你发的 pcap 文件，现在的 Chromium 发送的 QUIC Initial 确实跟去年这时候 Chromium 发送的 QUIC Initial 不太一样了，序号为 1 的 QUIC Initial packet 已经有 offset + length 大于包长度的情况。 |
我们是否可以修正这个问题呢？或者有没有避免这个问题的方法？（我有尝试在sniffing配置中去掉quic，但是好像没有作用） |
|
更新一个解决方法：使用fakeDNS和metadataOnly来避免调用SniffQUIC。 |
|
我也是ios chrome 出现该问题 最近几日更新的chrome |
|
同LZ |
|
update: 目前使用的最新版的v2ray V5.16.1 目前chrome IOS 我从最新版本133.x.x.x 降级回132.x.x.x的最后一个版本没出现过LZ类似情况，静待修复。 V2rayA 配置如下 |
有更多人上报这个问题，开发人员应该会更快去解决它。 |
|
#2886 can prevent the crash, and FYI I once bumped into a potential much better fix in https://github.com/Vigilans/v2ray-core/blob/dev/common/protocol/quic/sniff.go by the author of the current QUIC sniffer. It is up to the author anyway. |
thks |
楼上貌似有修复方案 |
@Vigilans Could you please help comment on this? |
|
related issue #3306 |
|
遇到了同样的问题，也是昨天升级chrome到133版本就出现这个问题了 |
我在linux平台下，升级chrome到133版本出现了这个问题 |
|
我可以先把panic的问题通过不处理分片 (#2886) 的方式避免，但是对于具体的sniff的实现大概需要有人提交能用的重组sniffer实现PR来完成。 |
感谢，这样可以先缓解这个问题。 |
我本来打算攒一波commit后一起发给上游，后来没时间整理慢慢就忘了……我先把这个最重要的发一下吧 |
I added some more changes at commit 45aaf35 after that commit, you can have a look at it. They are not criticial, just to prevent potential failure in QUIC sniffing.
|
|
Thanks @Vigilans for your job！ |
你好LZ，不知道您是否已经完美解决问题，如果是，可以告知如何解决吗，感谢！ |
Vigilans已经提交了PR，release之后即可解决问题，可以关注PR的合并和版本的发布。 |
|
Have same problem, tell please, how to patch v2raya client installed on openwrt, version 2.2.6.3, last xray core version |
|
This should be fixed in v5.29.0. |
cooooooooooooool thks boss |
|
Many thanks for all contributors， I will close it. |
使用TUN时出现panic，随后TUN网卡被关闭不能访问。
类似问题有 #2343 。此问题中提及是MTU过大的异常，但是TUN网卡MTU是1500，应该不会导致这个问题。
调试后发现似乎iPad和MAC的Chrome浏览器使用时会触发上述异常，怀疑与特定软件有关；作为对比，Safari没有触发异常。
请开发人员予以确认，是否能够解决或者有代替方案。（例如是否UDP下有此问题，TCP是正常的？不过使用TUN的一个重要愿意是比较完美支持UDP）
该问题最初在v5.16上发生（2/6首次出现，之前使用没有异常），升级至最新版本无法解决。
谢谢~
Feb 7 18:30:56 localhost v2ray[2251]: panic: runtime error: slice bounds out of range [:2280] with capacity 2048
Feb 7 18:30:56 localhost v2ray[2251]: goroutine 4410 [running]:
Feb 7 18:30:56 localhost v2ray[2251]: github.com/v2fly/v2ray-core/v5/common/protocol/quic.SniffQUIC({0xc0018c1000, 0x800, 0x800})
Feb 7 18:30:56 localhost v2ray[2251]: #011github.jparrowsec.cn/v2fly/v2ray-core/v5/common/protocol/quic/sniff.go:221 +0x1ccb
Feb 7 18:30:56 localhost v2ray[2251]: github.com/v2fly/v2ray-core/v5/app/dispatcher.NewSniffer.func3({0xc00067d8c0?, 0x10?}, {0xc0018c1000?, 0xc00067d8d0?, 0x16abbc0?})
Feb 7 18:30:56 localhost v2ray[2251]: #011github.jparrowsec.cn/v2fly/v2ray-core/v5/app/dispatcher/sniffer.go:39 +0x25
Feb 7 18:30:56 localhost v2ray[2251]: github.com/v2fly/v2ray-core/v5/app/dispatcher.(*Sniffer).Sniff(0xc000f11590, {0x194aa18, 0xc000dc39b0}, {0xc0018c1000, 0x800, 0x800}, 0x3)
Feb 7 18:30:56 localhost v2ray[2251]: #011github.jparrowsec.cn/v2fly/v2ray-core/v5/app/dispatcher/sniffer.go:67 +0xcc
Feb 7 18:30:56 localhost v2ray[2251]: github.com/v2fly/v2ray-core/v5/app/dispatcher.sniffer.func1({0x194aa18, 0xc000dc39b0}, 0xc000dc3a40, 0xc001606ec0, 0xc000f11590, 0x3)
Feb 7 18:30:56 localhost v2ray[2251]: #011github.jparrowsec.cn/v2fly/v2ray-core/v5/app/dispatcher/default.go:267 +0x125
Feb 7 18:30:56 localhost v2ray[2251]: github.com/v2fly/v2ray-core/v5/app/dispatcher.sniffer({0x194aa18, 0xc000dc39b0}, 0xc000dc3a40, 0x0, 0x3)
Feb 7 18:30:56 localhost v2ray[2251]: #011github.jparrowsec.cn/v2fly/v2ray-core/v5/app/dispatcher/default.go:277 +0x170
Feb 7 18:30:56 localhost v2ray[2251]: github.com/v2fly/v2ray-core/v5/app/dispatcher.(*DefaultDispatcher).Dispatch.func1()
Feb 7 18:30:56 localhost v2ray[2251]: #011github.jparrowsec.cn/v2fly/v2ray-core/v5/app/dispatcher/default.go:223 +0x110
Feb 7 18:30:56 localhost v2ray[2251]: created by github.com/v2fly/v2ray-core/v5/app/dispatcher.(*DefaultDispatcher).Dispatch in goroutine 4440
Feb 7 18:30:56 localhost v2ray[2251]: #011github.jparrowsec.cn/v2fly/v2ray-core/v5/app/dispatcher/default.go:218 +0x32b
Feb 7 18:30:56 localhost systemd-networkd[680]: tun0: Link DOWN
Feb 7 18:30:56 localhost systemd-networkd[680]: tun0: Lost carrier
The text was updated successfully, but these errors were encountered: