BorshDeserialize can cause UB by copying zero sized objects with no safe Copy impl about borsh-rs

[frol]

Nope, we still need to address it

[frol]

Good call! Indeed, this unsafe is not playing well:

borsh-rs/borsh/src/de/mod.rs

Lines 274 to 284 in b510429

	} else if size_of::<T>() == 0 {
	let mut result = Vec::new();
	result.push(T::deserialize(buf)?);
	let p = result.as_mut_ptr();
	unsafe {
	forget(result);
	let len = len.try_into().map_err(|_| ErrorKind::InvalidInput)?;
	let result = Vec::from_raw_parts(p, len, len);
	Ok(result)
	}

@ailisp It seems that you have some experience with this area (near/borsh#41). Do you have the capacity to work on this issue?

[evgenykuzyakov]

I think there is no need to optimize zero size structure, so let's just use a loop here to create it. Obviously it would add an ability to create an a very large loop that wouldn't be limited by the input data size.

[nearmax]

Can this be closed @frol @matklad ?

[dtolnay]

Given that the repro code in #19 (comment) still compiles and still segfaults, and the bad unsafe in #19 (comment) is still present in master, I would say no.

[westy92]

FYI this issue is now in the GitHub Advisory Database with Moderate severity: GHSA-fjx5-qpf4-xjf2

Also in RUSTSEC: https://rustsec.org/advisories/RUSTSEC-2023-0033.html

Is there a plan to address this?

[frol]

@westy92 I will be happy to review a pull request. The issue is hypothetical, and you really need to setup yourself into a trouble to exercise it, so given the limited resources (no active contributors to this project), it is not going to be fixed any time soon unless someone from the community contributes the fix.

[frol]

A vector of zero-sized types is pointless in the context of serialization/deserialization in my opinion, so I believe the best thing is to just forbid collections of zero-size elements (#136 (comment)). I am wondering if there is a way to do it through the type system (in the worst case, we will do it at runtime).