Maybe unsound in CodeAttribute

[lwz23]

hello, thank you for your contribution in this project, I am scanning the unsoundness problem in rust project.
I notice the following code:

pub struct CodeAttribute {
    pub max_stack: u16,
    pub max_locals: u16,
    pub code_length: u32,
    pub code: *mut Vec<u8>,
    pub exception_table_length: u16,
    pub exception_table: Vec<Exception>,
    pub attributes_count: u16,
    pub attributes: Vec<AttributeInfo>,
}

impl CodeAttribute{
..............................
    pub fn read_u8_from_code(&self, start: usize) -> usize {
        let code = unsafe { &*self.code };
        code[start] as usize
    }
pub fn read_u16_from_code(&self, start: usize) -> usize {
        let code = unsafe { &*self.code };
        ((code[start] as usize) << 8) + code[start + 1] as usize
    }
pub fn dump_bytecode(&self) {
......................
}

Considering that pub mod class, code is a pub field, and read_u16_from_code read_u8_from_code........ are also pub function. I assume that users can directly manipulate this field. This potential situation could result in *self.code being dereference a null pointer, and directly dereferencing it might trigger undefined behavior (UB). For safety reasons, I felt it necessary to report this issue. If you have performed checks elsewhere that ensure this is safe, please don’t take offense at my raising this issue.
If there is no external usage for CodeAttribute, I suggest it should not marked as pub, at least its field should not marked as pub.

[lwz23]

ping

[maekawatoshiki]

Hi, I'll look into that. But this is my old codebase, so don't expect much of further information.

[lwz23]

Ok, thanks for your reply! I just want to comfirm whether this pattern is unsound.

[maekawatoshiki]

From your explanation, I think the pattern is unsound. It'd be better if you could explain the definition unsoundness though.

[lwz23]

Of course, thanks for your reply! Here is the definition of soundness in Rust:
Soundness is a type system concept (actually originating from the study of logics) and means that the type system is "correct" in the sense that well-typed programs actually have the desired properties. For Rust, this means well-typed programs cannot cause Undefined Behavior. This promise only extends to safe code however; for unsafe code, it is up to the programmer to uphold this contract.

Accordingly, we say that a library (or an individual function) is sound if it is impossible for safe code to cause Undefined Behavior using its public API. Conversely, the library/function is unsound if safe code can cause Undefined Behavior.

[maekawatoshiki]

Well, then my code here is unsound :)