My proxy server also behaves strange

help
1

This will overflow, I tested it on the same device.

./pqproxy/target/debug/pqproxy -a server -b '127.0.0.1:2251' -g '127.0.0.1:1024'

On the same device run

./pqproxy/target/debug/pqproxy -a client -g '127.0.0.1:2251'

The server side (it's on the same device that also runs the client) shows

thread '<unnamed>' panicked at 'capacity overflow', library/alloc/src/raw_vec.rs:518:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

or

memory allocation of 6438275382588823899 bytes failed
Aborted
2

This size in hex is:

0x595959595959595B

which looks like you're using some sentinel value as allocation size. Perhaps something has been filling the memory with 0x59 to indicate unintialized or freed regions. Double-check where the size comes from, and treat every unsafe related to it as very suspect.

Perhaps you're reading structure into uninitialized memory, and not checking if the buffer has been filled completely? For example, every use of read() instead of read_exact() is likely a bug (same for write() being a backstabbing bug-causing cousin of write_all()).

3

My code doesn't have unsafe keyword, so I don't know what's wrong. But I use 3rd-party crates, I didn't check whether those 3rd-party crates have unsafe or not.

4

Does read_exact() implemented for TcpStream read multiple packets to fill the buffer? It seems that single TCP packet can't be larger than 64KiB, but the buffer can be larger.

5

There are methods to_le_bytes(), to_be_bytes(), to_ne_bytes() for integers. Do from_le_bytes(), from_be_bytes(), from_ne_bytes() always successfully recover that integer?

6

read_exact() runs read() in a loop {}, because read() can read as little as 1 byte at a time.

7

These methods always succeed, but the bytes you fed to them look suspicious.

8

It'd be really helpful if you'd share the code.