Considering ptr casts -- add tests #1

apaznikov · 2024-10-29T06:12:24Z

Check if it works -- add tests

Example illustrating how IntToPtr can be used to create a pointer to an escaping object, translated into English:

C Code:

int *leak_example(int x) {
  int *p = (int *)(x + 10); // Create a pointer to an address calculated from x
  return p;                // Return the pointer
}

LLVM IR:

define dso_local i32* @leak_example(i32 %x) #0 {
entry:
  %add = add nsw i32 %x, 10  // Calculate the address
  %0 = inttoptr i32 %add to i32* // Convert the integer to a pointer
  ret i32* %0                 // Return the pointer
}

In this example:

The function leak_example takes an integer argument x.
Inside the function, an address is calculated by adding x to 10.
The inttoptr instruction converts the resulting integer to a pointer of type i32*.
The function returns the created pointer.

Problem:

We don't know what the created pointer refers to.
It might refer to a valid object in memory, but it could also point to unallocated memory or memory that has already been freed.
Consequently, dereferencing this pointer could lead to undefined behavior.

Leakage:

In this example, the pointer p escapes from the function leak_example.
If the caller uses this pointer without checking its validity, it might result in an error.

Escape Analysis:

Escape analysis must consider IntToPtr instructions since they can create pointers to escaping objects.
In this example, escape analysis should mark the pointer returned from leak_example as escaping.

Conclusion:

IntToPtr is a powerful instruction that allows you to work with memory at a low level.
However, its use requires caution as it can lead to undefined behavior and memory leaks.
Escape analysis must consider IntToPtr for accurate leak analysis.

The text was updated successfully, but these errors were encountered:

``` UBSan-Standalone-sparc :: TestCases/Misc/Linux/diag-stacktrace.cpp ``` `FAIL`s on 32 and 64-bit Linux/sparc64 (and on Solaris/sparcv9, too: the test isn't Linux-specific at all). With `UBSAN_OPTIONS=fast_unwind_on_fatal=1`, the stack trace shows a duplicate innermost frame: ``` compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:31: runtime error: execution reached the end of a value-returning function without returning a value #0 0x7003a708 in f() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:35 focs-lab#1 0x7003a708 in f() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:35 focs-lab#2 0x7003a714 in g() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:17:38 ``` which isn't seen with `fast_unwind_on_fatal=0`. This turns out to be another fallout from fixing `__builtin_return_address`/`__builtin_extract_return_addr` on SPARC. In `sanitizer_stacktrace_sparc.cpp` (`BufferedStackTrace::UnwindFast`) the `pc` arg is the return address, while `pc1` from the stack frame (`fr_savpc`) is the address of the `call` insn, leading to a double entry for the innermost frame in `trace_buffer[]`. This patch fixes this by moving the adjustment before all uses. Tested on `sparc64-unknown-linux-gnu` and `sparcv9-sun-solaris2.11` (with the `ubsan/TestCases/Misc/Linux` tests enabled). (cherry picked from commit 3368a32)

apaznikov changed the title ~~Considering ptr casts~~ Considering ptr casts -- add tests Nov 7, 2024

apaznikov closed this as completed Nov 11, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Considering ptr casts -- add tests #1

Considering ptr casts -- add tests #1

Considering ptr casts -- add tests #1

Considering ptr casts -- add tests #1

Comments

Check if it works -- add tests