4 ms·

To parody the evergreen The Onion headline "No way to prevent this" says proprietary codebases where this always happens

• tialaramex 1y ago
  I've always thought the correct analogy was: "No way to prevent this" say programmers of only languages where this regularly happens. This only happens if you have the worst version of Tony's Billion Dollar Mistake. So C, C++, Zig, Odin and so on but not Rust. It's a use-after-free, a category of mistake that's impossible in true GC languages, and also impossible in safe Rust. We have known, for many years, how to not have this problem, but some people who ought to know better insist they can't stop it, exactly like America's gun violence.
  • jibal 1y ago
    Zig pointers are non-null. Optionally null pointers must be explicitly unwrapped.
    • noitpmeder 1y ago
      so... references and pointers? What is my_ptr->member but unwrapping an optionally null pointer.
      • davemp 1y ago
        It’s semantics. Zig can still have dangling references/uaf. You can do something like ‘var foo: *Bar = @intToPtr(0x00)’ but in order to “properly” use the zero address to represent state you have to use ‘var foo: ?*Bar = null’ which is a different type than ‘*Bar’ that the compiler will force you to check before accessing. It’s the whole make it easy to write good code—not impossible to write incorrect code philosophy of the language.
        • pjmlp 1y ago
          Thus it would not prevent a CVE like the one being discussed.
          • davemp 1y ago
            Judging from the article, Zig would have prevented the CVE. > This includes memory allocations of type NV01_MEMORY_DEVICELESS which are not associated with any device and therefore have the pGpu field of their corresponding MEMORY_DESCRIPTOR structure set to null This does look like the type of null deref that Zig does prevent. Looking at the second issue in the chain, I believe standard Zig would have prevented that as well. The C code had an error that caused the call to free to be skipped: threadStateInit(&threadState, THREAD_STATE_FLAGS_NONE); status = rmapiMapWithSecInfo(/*…*/); // null deref here threadStateFree(&threadState, THREAD_STATE_FLAGS_NONE); Zig’s use of ‘defer’ would ensure that free is called even if an error occurred: threadStateInit(&threadState, THREAD_STATE_FLAGS_NONE); defer threadStateFree(&threadState, THREAD_STATE_FLAGS_NONE); status = try rmapiMapWithSecInfo(/*…*/); // null deref here
            • pjmlp 1y ago
              Assuming the user would not have forgotten to type the line with defer, and correctly as well, like all great coders. Followed by never touching the variable ever again.
              • davemp 1y ago
                Nothing can prevent a sufficiently belligerent programmer from writing bad code. Not even Rust—which I assume you’re advocating for without reading the greater context of this thread.
                • tialaramex 1y ago
                  We're literally in a thread about the famous Onion recurring story. "'No Way to Prevent This,' Says Only Nation Where This Regularly Happens"
      • jibal 1y ago
        > What is my_ptr->member but unwrapping an optionally null pointer. It's a dereference of a pointer that might be null and thereby yield undefined behavior; there's no required unwrapping under an explicit test for null, as is required by Zig. In Zig, my_ptr cannot be null in my_ptr.member -- null is not a valid pointer value. If my_ptr is an optionally null pointer then the pointer value must be unwrapped by first checking whether it is null ... the dereference can only occur in the test branch where the pointer isn't null. Note that the mention of Zig that I responded to was in reference to Tony Hoare's "billion dollar mistake", which was making null a valid value of a pointer type. As I noted, the mistake doesn't occur in Zig because null is not a valid value for a pointer, only an optional pointer, which must be unwrapped with an explicit null test. If you had no idea what I was referring to, you might have asked. Rather, you asked a rhetorical question with no question mark, implying the falsehood that my_ptr->member is "unwrapping an optionally null pointer" when it's nothing of the sort.
    • pjmlp 1y ago
      Assuming they are still valid, Zig doesn't prevent use after free.
      • jibal 1y ago
        > This only happens if you have the worst version of Tony's Billion Dollar Mistake. So C, C++, ==> Zig <==, Odin and so on but not Rust. The billion dollar mistake is making NULL a valid pointer value, not use after free--which has nothing to do with null pointers and which I didn't comment on, as the comment I responded to only mentioned Zig in regard to the billion dollar mistake. The billion dollar mistake doesn't occur in Zig because null is not a valid value for a pointer, only an optional pointer, which must be unwrapped with an explicit null test.
        • tialaramex 1y ago
          I agree that's an error on my part - Zig does not actually have the billion dollar mistake, although I don't think the approach taken is very good it's clearly not just the billion dollar mistake and so I was wrong to say that.
          • jibal 1y ago
            > although I don't think the approach taken is very good The approach taken is the same as in virtually every other language that has avoided the billion dollar mistake -- null is not a valid pointer value, and instead there's an additional union type (called Optional, Maybe, etc.) that can hold Some(pointer) or None. Zig, like some other languages, extends this union beyond pointers to other types.