undefined | Better HN

0 pointsdavemp8mo ago0 comments

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

0 pointsdavemp8mo ago0 comments

Judging from the article, Zig would have prevented the CVE.

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

0 comments

5 comments · 1 top-level

pjmlp8mo ago· 4 in thread

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.

davempOP8mo 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.

vacuity8mo ago

Especially in the case of GP, I'd say Rust is not the main recommendation, although it is one. I would concur that Rust is only one of many decent languages (for memory safety or otherwise).

Still, there are languages with guardrails, and then there are languages with guardrails, and the order for memory safety is probably something like C < C++ < Zig < Rust < managed (GC) languages.

tialaramex8mo 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"

davempOP8mo ago

I literally replied with “A Way to Prevent This”?

1 more reply

j / k navigate · click thread line to collapse