2 ms·

> Segfault" is simply Go's reporting convention for things like nil pointer hits. Blatantly false. From Ralf’s post: > panic: runtime error: invalid memory ad

> Segfault" is simply Go's reporting convention for things like nil pointer hits. Blatantly false. From Ralf’s post: > panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x2a pc=0x468863] The panic address is 42, a value being mutated, not a nil pointer. You could easily imagine this address pointing to a legal but unintended memory address resulting in a read or write of unintended memory.

tptacek 11mo ago
No, you can't, and the reason you know you can't is that it's never happened. That looks like a struct offset dereference from a nil pointer, for what it's worth. https://go.dev/play/p/0fUzmP0cLEa https://go.dev/play/p/0fUzmP0cLEa
- vlovich123 11mo ago
  You’d be wrong. I recommend you reread the blog post and grok what’s happening in the example. > When that happens, we will run the Ptr version of get, which will dereference the Int’s val field as a pointer – and hence the program accesses address 42, and crashes. If you don’t see an exploit gadget there based on a violation of memory safety I don’t know how to have a productive conversation.
  - tptacek 11mo ago
    Please do explain the exploit gadget you're talking about.
- josefx 11mo ago
  > That looks like a struct offset dereference from a nil pointer, for what it's worth. The 42 is an explicit value in the example code. From what I understand the code repeatedly changes the value assigned to an interface variable from an object containing a pointer to an object containing an integer. Since interface variables store the type of the assigned value, but do not update both type and value atomically a different thread can interpret whatever integer you put into it as a valid pointer. Putting a large enough value into the integer should avoid the protected memory page around 0 and allow for some old fashioned memory corruption.

tptacek 11mo ago

No, you can't, and the reason you know you can't is that it's never happened. That looks like a struct offset dereference from a nil pointer, for what it's worth. https://go.dev/play/p/0fUzmP0cLEa https://go.dev/play/p/0fUzmP0cLEa

vlovich123 11mo ago
You’d be wrong. I recommend you reread the blog post and grok what’s happening in the example. > When that happens, we will run the Ptr version of get, which will dereference the Int’s val field as a pointer – and hence the program accesses address 42, and crashes. If you don’t see an exploit gadget there based on a violation of memory safety I don’t know how to have a productive conversation.
- tptacek 11mo ago
  Please do explain the exploit gadget you're talking about.
josefx 11mo ago
> That looks like a struct offset dereference from a nil pointer, for what it's worth. The 42 is an explicit value in the example code. From what I understand the code repeatedly changes the value assigned to an interface variable from an object containing a pointer to an object containing an integer. Since interface variables store the type of the assigned value, but do not update both type and value atomically a different thread can interpret whatever integer you put into it as a valid pointer. Putting a large enough value into the integer should avoid the protected memory page around 0 and allow for some old fashioned memory corruption.