moulberry/graphite

1.19.1 high-performance Minecraft server

graphite's Issues

Transmute between `Vec` types in graphite NBT

In crates/graphite_binary/src/nbt/decode.rs there is this

let vec: Vec<u8> = arr_bytes.into();
Ok(unsafe { std::mem::transmute(vec) })

Transmuting between Vec types is incorrect because #[repr(Rust)] types make no guarantee about their layout. The Rustonomicon has this to say:

So how do you know if the layouts are the same? For repr(C) types and repr(transparent) types, layout is precisely defined. But for your run-of-the-mill repr(Rust), it is not. Even different instances of the same generic type can have wildly different layout. Vec<i32> and Vec<u32> might have their fields in the same order, or they might not. The details of what exactly is and is not guaranteed for data layout are still being worked out over at the UCG WG.

Please open a Discord server for communication.

I believe a Discord server would be a great start for the community.

Rewrite it in rust

Rust is blazingly fast and memory-efficient: with no runtime or garbage collector, it can power performance-critical services, run on embedded devices, and easily integrate with other languages.

Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — enabling you to eliminate many classes of bugs at compile-time.

Rust has great documentation, a friendly compiler with useful error messages, and top-notch tooling — an integrated package manager and build tool, smart multi-editor support with auto-completion and type inspections, an auto-formatter, and more.

Potential OOM bug/exploit in graphite NBT

In crates/graphite_binary/src/nbt/decode.rs the read_list function uses Vec::with_capacity(length as _). However, length has no upper bound. I believe malicious input could potentially allocate i32::MAX * sizeof(usize) bytes.

The other read functions are correctly bounded.

Players still receive viewable packets from despawned entities

Entities which have been despawned due to player movement will still send packets to players (for 1 tick)

This can be fixed by only sending viewable packets if the chunk is within BOTH chunk_view_position and new_chunk_view_position

no readme

a README.md is a great way to tell people what the heck your project is, how to help build it, and how to test what you’ve made. once you’re at the point where others can help, i’d highly recommend making one