Pumpkin-MC/Pumpkin · error · std::io::Error
user_data_len exceeds 1MB limit
Error message
user_data_len exceeds 1MB limit
What it means
Raised while reading a Bedrock network item's user data: the VarUInt-prefixed length field claims more than 1,048,576 bytes (1MB). The reader rejects it before allocating the buffer, protecting against corrupted or malicious packets that would otherwise trigger huge allocations.
Solutions
- Confirm the packet stream is being read from the correct offset — desync makes garbage bytes look like lengths.
- Ensure the client/server protocol versions match; mismatched versions change item encoding.
- Treat it as a malformed-packet signal: drop the packet/connection rather than retrying the same bytes.
- If sending side, keep user data under 1MB and clamp before writing.
Example fix
// before
let data = read_item_user_data(buf)?; // panics/allocs on huge len
// after
match read_item_user_data(buf) {
Ok(d) => d,
Err(e) if e.kind() == ErrorKind::InvalidData => { disconnect("malformed item"); }
Err(e) => return Err(e),
} Defensive patterns
Strategy: try-catch
Try / catch
match NetworkItem::read(buf) {
Ok(item) => item,
Err(e) if e.to_string().contains("1MB limit") => {
log::warn!("malformed item packet rejected");
drop_packet();
}
Err(e) => return Err(e),
} Prevention
- Keep item user data under 1MB when writing.
- On this error, suspect stream desync — validate prior field reads.
- Verify client/server protocol version parity.
When it happens
Trigger: Deserializing a network item (read path at network_item.rs:52) where the user_data_len varint exceeds 1MB — caused by stream desync, corrupt data, or crafted packets.
Common situations: Malicious client sends an inflated length field; packet parsing drifted out of sync so a data byte is misread as a length; corrupted save/network data.
Understand the failure class
Background: payload too large / request exceeds maximum size: why libraries cap bytes and how to fix oversize payloads — this error's family across 50 libraries.
Related errors
- extra_data_len exceeds 1MB limit
- Invalid ContainerName ID
- item string array length out of bounds
- String::from_utf8 error
- Nbt read error
AI-assisted analysis of Pumpkin-MC/Pumpkin@8d4639e25a (2026-09-09).
Data as JSON: /api/errors/39c2970503fbaf73.
Report an issue: GitHub.
Appendix: source
Thrown at crates/pumpkin-protocol/src/bedrock/network_item.rs:52
}
}
impl PacketRead for NetworkItemDescriptor {
fn read<R: Read>(buf: &mut R) -> Result<Self, Error> {
let id = VarInt(i32::from(i16::read(buf)?));
let stack_size = u16::read(buf)?;
let aux_value = VarUInt::read(buf)?;
let has_net_id = bool::read(buf)?;
if has_net_id {
let _net_id = VarInt::read(buf)?;
}
let block_runtime_id = VarInt(VarUInt::read(buf)?.0 as i32);
let user_data_len = VarUInt::read(buf)?.0 as usize;
if user_data_len > 1_048_576 {
return Err(Error::new(
ErrorKind::InvalidData,
"user_data_len exceeds 1MB limit",
));
}
let mut user_data = vec![0u8; user_data_len];
buf.read_exact(&mut user_data)?;
let (nbt_data, place_on_blocks, destroy_blocks, shield_blocking_tick) =
read_user_data(user_data, id.0 == i32::from(BedrockItem::SHIELD.id))?;
Ok(Self {
id,
stack_size,
aux_value,
block_runtime_id,
nbt_data,
place_on_blocks,
destroy_blocks,View on GitHub (pinned to 8d4639e25a)