Solution for panic: runtime error: slice bounds out of range [2:0] #1501

zerodwide · 2023-01-08T13:27:46Z

Greatings!

I have lot of users on simple VLESS+TCP+XTLS config, which most of time is okay, but every 5-15 minutes i have a panic and crash Xray for about 30 seconds.
I don't know how this error occurs, but it is exists on all versions of Xray (until latest 1.7) have this weird bug:

panic: runtime error: slice bounds out of range [2:0]

also lots of other people has this issue, for example: #1422

Solution:

i looked the exact line of code which cause this error, and found out that in an array never low index be higher than high index, [A:B], so never A should be higher than B, and i don't know it happening! its not logical, buy may in some other parts of code which main developers are aware of, A became higher than B, then i add a compare between A and B, that never A be higher than B, And it solved the panic for ever!:

file: github.com/xtls/xray-core/common/buf/buffer.go:253

// Read implements io.Reader.Read().
func (b *Buffer) Read(data []byte) (int, error) {
	if b.Len() == 0 {
		return 0, io.EOF
	}
        // this is line 253
	nBytes := copy(data, b.v[b.start:b.end])
	if int32(nBytes) == b.Len() {
		b.Clear()
	} else {
		b.start += int32(nBytes)
	}
	return nBytes, nil
}

I added this line of code above line 253

	if b.start >= b.end {
		return 0, io.EOF
	}

Dear @RPRX

Q1: I ask you to check the code and include it in next version
Q2: is "return 0, io.EOF" is best return for such that illogical inputs?

final code:

// Read implements io.Reader.Read().
func (b *Buffer) Read(data []byte) (int, error) {
	if b.Len() == 0 {
		return 0, io.EOF
	}
	if b.start >= b.end {
		return 0, io.EOF
	}
	nBytes := copy(data, b.v[b.start:b.end])
	if int32(nBytes) == b.Len() {
		b.Clear()
	} else {
		b.start += int32(nBytes)
	}
	return nBytes, nil
}

full panic log:

goroutine 1699405 [running]:
github.com/xtls/xray-core/common/buf.(*Buffer).Read(...)
github.com/xtls/xray-core/common/buf/buffer.go:253
github.com/xtls/xray-core/common/buf.SplitBytes({0xc00c62b7d8, 0x1, 0x1}, {0xc007b5a000?, 0xc00b170e70?, 0xc006a07dfc?}) github.com/xtls/xray-core/common/buf/multi_buffer.go:105 +0x290
github.com/xtls/xray-core/common/buf.(*BufferedReader).Read(0xc00bce2570, {0xc007b5a000?, 0xc00bb9e060?, 0x0?}) github.com/xtls/xray-core/common/buf/reader.go:68 +0x92 io.ReadAtLeast({0x11ca3c0, 0xc00bce2570}, {0xc007b5a000, 0x2e, 0x2000}, 0x2e) io/io.go:332 +0x9a io.ReadFull(...)
io/io.go:351
github.com/xtls/xray-core/common/buf.(*Buffer).ReadFullFrom(0xc00bb9e060?, {0x11ca3c0?, 0xc00bce2570?}, 0x2?)
github.com/xtls/xray-core/common/buf/buffer.go:276 +0x85 github.com/xtls/xray-core/proxy/vless/encoding.(*LengthPacketReader).ReadMultiBuffer(0xc002c2dfb0) github.com/xtls/xray-core/proxy/vless/encoding/addons.go:180 +0x205
github.com/xtls/xray-core/common/buf.copyInternal({0x11cb1c0, 0xc002c2dfb0}, {0x11c9700, 0xc00bb6abc0}, 0xc00b7338a8)
github.com/xtls/xray-core/common/buf/copy.go:81 +0x69 github.com/xtls/xray-core/common/buf.Copy({0x11cb1c0, 0xc002c2dfb0}, {0x11c9700, 0xc00bb6abc0}, {0xc001394f20, 0x1, 0xc001394f18?})
github.com/xtls/xray-core/common/buf/copy.go:104 +0xa5 github.com/xtls/xray-core/proxy/vless/inbound.(*Handler).Process.func4()
github.com/xtls/xray-core/proxy/vless/inbound/inbound.go:514 +0x1f9
github.com/xtls/xray-core/common/task.OnSuccess.func1()
github.com/xtls/xray-core/common/task/task.go:12 +0x25
github.com/xtls/xray-core/common/task.Run.func1(0xc0005c2001?)
github.com/xtls/xray-core/common/task/task.go:28 +0x2e
created by github.com/xtls/xray-core/common/task.Run github.com/xtls/xray-core/common/task/task.go:27 +0xde

The text was updated successfully, but these errors were encountered:

cross-hello · 2023-01-08T13:59:47Z

Why line 253 nBytes will read more date than the length of b.Len()...
nBytes := copy(data, b.v[b.start:b.end])

zerodwide · 2023-01-08T14:58:06Z

@cross-hello I don't know! its weird.

but by my code it will be fixed permanently.

cross-hello · 2023-01-08T15:00:39Z

Why you don't change the code to
if int32(nBytes) >= b.Len()
It more Cleaner, isn't it?

zerodwide · 2023-01-08T18:08:49Z

@cross-hello
The main problem is sometimes for unknown reasons b.start became higher than b.end
does your code ensures b.start won't be higher than b.end?

cross-hello · 2023-01-08T18:15:58Z

We doubt the bytes count of b may be corrupt inside concurrency, where memory lock is lacking in. Jan 9, 2023 02:09:00 Zero Dwide ***@***.***>:

…

@cross-hello[https://github.com/cross-hello] The main problem is sometimes for unknown reasons *b.start* became higher than *b.end* does your code ensures *b.start* won't be higher than *b.end*? — Reply to this email directly, view it on GitHub[#1501 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYDW7TTCPTBUF5RY27LWRL7DXANCNFSM6AAAAAATUSLWQU]. You are receiving this because you were mentioned.[Tracking image][https://github.com/notifications/beacon/AKGBAYFY5XZQJT4LAZUY6L3WRL7DXA5CNFSM6AAAAAATUSLWQWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSR6M4I4.gif]

RPRX · 2023-01-09T03:15:40Z

之前有一个修复是 c880b91 ，但它是处理外部传入的 to

b.start 和 b.end 是私有字段，小概率是 @cross-hello 说的情况，大概率是 buffer.go 自己的代码造成了 b.start > b.end，请排查

RPRX · 2023-01-09T03:19:30Z

~~大致看了一眼，看起来很多时候 b.start 在 += 时并没有判断 b.end~~

asiaqa · 2023-01-09T05:30:18Z

剛剛在Apline Linux Docker 复现这个情况：

panic: runtime error: slice bounds out of range [:538] with capacity 0

goroutine 1293 [running]:
github.com/xtls/xray-core/common/buf.(*Buffer).BytesRange(...)
/github/workspace/tmp/common/buf/buffer.go:141
github.com/xtls/xray-core/proxy/vless/encoding.XtlsUnpadding({0x8f3a2e0, 0xb8117a0}, {0xb2e7ac0, 0x1, 0x1}, {0xa7e1520, 0x10, 0x10}, 0xa9a0dac, 0xa9a0da8, ...)
/github/workspace/tmp/proxy/vless/encoding/encoding.go:579 +0xd08
github.com/xtls/xray-core/proxy/vless/encoding.XtlsRead.func1({0x8f3a2e0, 0xb8117a0}, {0x8f3e2a0, 0xb2e7a30}, {0x0, 0x0}, {0x8f39c4c, 0xb2e7ae0}, 0xa9a0eb8, 0xaba7702, ...)
/github/workspace/tmp/proxy/vless/encoding/encoding.go:298 +0x45a
github.com/xtls/xray-core/proxy/vless/encoding.XtlsRead({0x8f309f0, 0xb6c0b28}, {0x8f31940, 0xb2e7b20}, {0x8f30d38, 0xbb90480}, {0x8f3e2a0, 0xb2e7a30}, {0x8f39c4c, 0xb2e7ae0}, ...)
/github/workspace/tmp/proxy/vless/encoding/encoding.go:336 +0x11f
github.com/xtls/xray-core/proxy/vless/inbound.(*Handler).Process.func4()
/github/workspace/tmp/proxy/vless/inbound/inbound.go:566 +0x42d
github.com/xtls/xray-core/common/task.OnSuccess.func1()
/github/workspace/tmp/common/task/task.go:12 +0x23
github.com/xtls/xray-core/common/task.Run.func1(0xb6545f0)
/github/workspace/tmp/common/task/task.go:28 +0x2b
created by github.com/xtls/xray-core/common/task.Run
/github/workspace/tmp/common/task/task.go:27 +0xbe

cross-hello · 2023-01-09T05:33:45Z

Does this the cause for *ray series memories leaking? Jan 9, 2023 13:30:29 MP ***@***.***>:

…

剛剛在Apline Linux Docker 复现这个情况： panic: runtime error: slice bounds out of range [:538] with capacity 0 goroutine 1293 [running]: github.com/xtls/xray-core/common/buf.(*Buffer).BytesRange(...) /github/workspace/tmp/common/buf/buffer.go:141 github.com/xtls/xray-core/proxy/vless/encoding.XtlsUnpadding({0x8f3a2e0, 0xb8117a0}, {0xb2e7ac0, 0x1, 0x1}, {0xa7e1520, 0x10, 0x10}, 0xa9a0dac, 0xa9a0da8, ...) /github/workspace/tmp/proxy/vless/encoding/encoding.go:579 +0xd08 github.com/xtls/xray-core/proxy/vless/encoding.XtlsRead.func1({0x8f3a2e0, 0xb8117a0}, {0x8f3e2a0, 0xb2e7a30}, {0x0, 0x0}, {0x8f39c4c, 0xb2e7ae0}, 0xa9a0eb8, 0xaba7702, ...) /github/workspace/tmp/proxy/vless/encoding/encoding.go:298 +0x45a github.com/xtls/xray-core/proxy/vless/encoding.XtlsRead({0x8f309f0, 0xb6c0b28}, {0x8f31940, 0xb2e7b20}, {0x8f30d38, 0xbb90480}, {0x8f3e2a0, 0xb2e7a30}, {0x8f39c4c, 0xb2e7ae0}, ...) /github/workspace/tmp/proxy/vless/encoding/encoding.go:336 +0x11f github.com/xtls/xray-core/proxy/vless/inbound.(*Handler).Process.func4() /github/workspace/tmp/proxy/vless/inbound/inbound.go:566 +0x42d github.com/xtls/xray-core/common/task.OnSuccess.func1() /github/workspace/tmp/common/task/task.go:12 +0x23 github.com/xtls/xray-core/common/task.Run.func1(0xb6545f0) /github/workspace/tmp/common/task/task.go:28 +0x2b created by github.com/xtls/xray-core/common/task.Run /github/workspace/tmp/common/task/task.go:27 +0xbe — Reply to this email directly, view it on GitHub[#1501 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYAYNF4KZ2WGJYFZOPDWROO7LANCNFSM6AAAAAATUSLWQU]. You are receiving this because you were mentioned.[Tracking image][https://github.com/notifications/beacon/AKGBAYD5LO36OECSH5AGEJLWROO7LA5CNFSM6AAAAAATUSLWQWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSR627US.gif]

RPRX · 2023-01-09T09:02:59Z

我详细查看了代码，并提交了 7b8ff01 以确保任何时候 0 <= b.start <= b.end，请测试该 commit，若仍有问题，请开新的 issue

@asiaqa 你发的是另一个问题，请开新的 issue 并 @yuhan6665

RPRX · 2023-01-09T09:35:42Z

（buffer.go 的其它代码理论上本就可以确保 0 <= b.start <= b.end，无需为此修改）

yuhan6665 · 2023-01-09T14:32:02Z

Unpadding 这个我研究一下

cross-hello · 2023-01-10T02:42:38Z

This time using xray as client for a day without restart still could get a normal performance, unlike before, if without restart for some days the speed will slow down much. But it is still in time observing.

asiaqa · 2023-01-10T05:28:29Z

Unpadding 这个我研究一下

謝謝兩位大佬！

zerodwide · 2023-01-14T13:18:08Z

Thanks everybody for contribution.

@RPRX when we have it in next release?

moradianali · 2023-01-23T15:43:45Z

Considering that I am using the latest version, I still get the following 2 errors

Solution for panic: runtime error: slice bounds out of range [2:0]
Solution for panic: runtime error: slice bounds out of range [28:0]

RPRX · 2023-01-23T15:59:34Z

@zerodwide @moradianali Use the latest commit, not the latest version.

看来下次需要连发两个版本，bugfix 专版 v1.7.3，和 Reality 专版 v1.8.0

moradianali · 2023-01-23T16:22:41Z

Thank You . This problem is very annoying. When will the new version be released?

Fixes XTLS/Xray-core#1501

RPRX closed this as completed in 7b8ff01 Jan 9, 2023

rosebe mentioned this issue Jan 10, 2023

Add new uTLS fingerprints && Refine the logic of security type AUTO && Make sure that 0 <= b.start <= b.end && Add sockopt interface setting for binding outbound to a particular device like "eth0" (XTLS#1494) rosebe/Xray-core#36

Merged

yuhan6665 mentioned this issue Jan 11, 2023

Add buffer length sanity check #1520

Closed

mwhorse46 added a commit to mwhorse46/Xray-core that referenced this issue Feb 19, 2023

Make sure that 0 <= b.start <= b.end

79bfd33

Fixes XTLS/Xray-core#1501

rampagekiller0725 added a commit to rampagekiller0725/wox that referenced this issue Jun 29, 2023

Make sure that 0 <= b.start <= b.end

a42b5c4

Fixes XTLS/Xray-core#1501

Autumn216 added a commit to Autumn216/wox that referenced this issue Oct 31, 2023

Make sure that 0 <= b.start <= b.end

8b7f62e

Fixes XTLS/Xray-core#1501

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Solution for panic: runtime error: slice bounds out of range [2:0] #1501

Solution for panic: runtime error: slice bounds out of range [2:0] #1501

zerodwide commented Jan 8, 2023

cross-hello commented Jan 8, 2023

zerodwide commented Jan 8, 2023

cross-hello commented Jan 8, 2023

zerodwide commented Jan 8, 2023

cross-hello commented Jan 8, 2023 via email

RPRX commented Jan 9, 2023

RPRX commented Jan 9, 2023

asiaqa commented Jan 9, 2023

cross-hello commented Jan 9, 2023 via email

RPRX commented Jan 9, 2023

RPRX commented Jan 9, 2023

yuhan6665 commented Jan 9, 2023

cross-hello commented Jan 10, 2023

asiaqa commented Jan 10, 2023

zerodwide commented Jan 14, 2023 •

edited

Loading

moradianali commented Jan 23, 2023

RPRX commented Jan 23, 2023

moradianali commented Jan 23, 2023

Solution for panic: runtime error: slice bounds out of range [2:0] #1501

Solution for panic: runtime error: slice bounds out of range [2:0] #1501

Comments

zerodwide commented Jan 8, 2023

cross-hello commented Jan 8, 2023

zerodwide commented Jan 8, 2023

cross-hello commented Jan 8, 2023

zerodwide commented Jan 8, 2023

cross-hello commented Jan 8, 2023 via email

RPRX commented Jan 9, 2023

RPRX commented Jan 9, 2023

asiaqa commented Jan 9, 2023

cross-hello commented Jan 9, 2023 via email

RPRX commented Jan 9, 2023

RPRX commented Jan 9, 2023

yuhan6665 commented Jan 9, 2023

cross-hello commented Jan 10, 2023

asiaqa commented Jan 10, 2023

zerodwide commented Jan 14, 2023 • edited Loading

moradianali commented Jan 23, 2023

RPRX commented Jan 23, 2023

moradianali commented Jan 23, 2023

zerodwide commented Jan 14, 2023 •

edited

Loading