Rust: Query for dereferencing an invalid pointer

[geoffw0]

New query rust/access-invalid-pointer that spots dereferences of pointers that are invalid to dereference. There are tests for two general cases, but this query is only intended to catch the first one:

• (this query) dereference after a pointer is explicitly made invalid, for example by calling a dealloc function before dereferencing. Analogous to cpp/use-after-free.
  • an edge case we don't cover yet is when the deallocation is done through a distinct pointer to the same memory.
• (future query) dereference of a pointer after the lifetime of the thing it points two has (implicitly) ended.

TODO:

• DCA run
• code review
• docs review

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[github-actions]

QHelp previews:

rust/ql/src/queries/security/CWE-825/AccessInvalidPointer.qhelp

Access of invalid pointer

Dereferencing an invalid or dangling pointer is undefined behavior. Memory may be corrupted causing the program to crash or behave incorrectly, in some cases exposing the program to potential attacks.

Recommendation

When dereferencing a pointer in unsafe code, take care that the pointer is valid and points to the intended data. Code may need to be rearranged or additional checks added to ensure safety in all circumstances. If possible, rewrite the code using safe Rust types to avoid this class of problems altogether.

Example

In the following example, std::ptr::drop_in_place is used to execute the destructor of an object. However, a pointer to that object is dereferenced later in the program, causing undefined behavior:

unsafe {
    std::ptr::drop_in_place(ptr); // executes the destructor of `*ptr`
}

// ...

unsafe {
    do_something(&*ptr); // BAD: dereferences `ptr`
}

In this case undefined behavior can be avoided by rearranging the code so that the dereference comes before the call to std::ptr::drop_in_place:

unsafe {
    do_something(&*ptr); // GOOD: dereferences `ptr` while it is still valid
}

// ...

{
    std::ptr::drop_in_place(ptr); // executes the destructor of `*ptr`
}

References

• Rust Documentation: Behavior considered undefined >> Dangling pointers.
• Rust Documentation: Module ptr - Safety.
• Massachusetts Institute of Technology: Unsafe Rust - Dereferencing a Raw Pointer.
• Common Weakness Enumeration: CWE-476.
• Common Weakness Enumeration: CWE-825.

[geoffw0]

@hvitved this is a workaround because the sinks with access path "Argument[0]" weren't working as written. I'm not sure if I've made a trivial mistake or whether something is wrong in the MaD library?

[geoffw0]

DCA:

• lots of new query sinks in all projects; this is unsurprising as dereferences are considered a sink for this query and they're quite common.
  • we should probably block flow past sinks to prevent excessive data flow and potentially reporting lots of similar results.
• 8 query results across 4 projects.
  • most are inside Drop implementations, which is not something the query design anticipated and I need to look into whether they're acceptable results.