You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello 🦀 ,
we (Rust group @sslab-gatech) found a memory-safety/soundness issue in this crate while scanning Rust code on crates.io for potential vulnerabilities.
let read = r.read(&mutself.data[len..end]).map_err(CfbError::Io)?;
if read == 0{
returnOk(&self.data[start..len]);
}
len += read;
}
}
Ok(&self.data[start..end])
}
Issue#1: Write to unclaimed memory.
self.data.set_len(end) is done without reserving extra memory for self.data.
After that, new data is written to the unclaimed memory via r.read(&mut self.data[len..end]). This seems to be a critical security error, as r.read(&mut self.data[len..end]) can potentially write to memory that is actively occupied by another entity.
Issue#2: read() on uninitialized memory can cause undefined behavior
r.read(&mut self.data[len..end]) can potentially pass uninitialized memory to user-provided Read implementation. This is unsound, because it allows safe Rust code to exhibit an undefined behavior (read from uninitialized memory).
This part from the Read trait documentation explains the issue:
It is your responsibility to make sure that buf is initialized before calling read. Calling read with an uninitialized buf (of the kind one obtains via MaybeUninit<T>) is not safe, and can lead to undefined behavior.
Suggested Fix
It would be safe to zero-initialize the newly allocated u8 buffer before read()
(probably via self.data.resize(end - len, 0)),
in order to prevent user-provided Read from accessing old contents of the newly allocated heap memory.
Thank you for checking out this issue 👍
The text was updated successfully, but these errors were encountered:
Once a fix is released to crates.io, please open a pull request to update the advisory with the patched version, or file an issue on the advisory database repository.
dodomorandi
added a commit
to dodomorandi/calamine
that referenced
this issue
Feb 1, 2021
Hello 🦀 ,
we (Rust group @sslab-gatech) found a memory-safety/soundness issue in this crate while scanning Rust code on crates.io for potential vulnerabilities.
calamine/src/cfb.rs
Lines 243 to 261 in 2391d0c
Issue#1: Write to unclaimed memory.
self.data.set_len(end)
is done without reserving extra memory forself.data
.After that, new data is written to the unclaimed memory via
r.read(&mut self.data[len..end])
.This seems to be a critical security error, as
r.read(&mut self.data[len..end])
can potentially write to memory that is actively occupied by another entity.Issue#2:
read()
on uninitialized memory can cause undefined behaviorr.read(&mut self.data[len..end])
can potentially pass uninitialized memory to user-providedRead
implementation. This is unsound, because it allows safe Rust code to exhibit an undefined behavior (read from uninitialized memory).This part from the
Read
trait documentation explains the issue:Suggested Fix
It would be safe to zero-initialize the newly allocated
u8
buffer beforeread()
(probably via
self.data.resize(end - len, 0)
),in order to prevent user-provided
Read
from accessing old contents of the newly allocated heap memory.Thank you for checking out this issue 👍
The text was updated successfully, but these errors were encountered: