Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix a subtle uninitialized-memory-read in Buffer::for_each_value() #7330

Merged
merged 4 commits into from
Feb 10, 2023

Conversation

steven-johnson
Copy link
Contributor

When we flattened dimensions in for_each_value_prep(), we would copy from one past the end, meaning the last element contained uninitialized garbage. (This wasn't noticed as an out-of-bounds read because we overallocated in structure in for_each_value_impl()). This garbage stride was later used to advance ptrs in for_each_value_helper()... but only on the final iteration, so even if the ptr was wrong, it didn't matter, as the ptr was never used again. Under certain MSAN configurations, though, the read would be (correctly) flagged as uninitialized.

This fixes the MSAN bug, and also (slightly) improves the efficiency by returning the post-flattened number of dimensions, potentially reducing the number of iterations f for_each_value_helper() needed.

When we flattened dimensions in for_each_value_prep(), we would copy from one past the end, meaning the last element contained uninitialized garbage. (This wasn't noticed as an out-of-bounds read because we overallocated in structure in for_each_value_impl()). This garbage stride was later used to advance ptrs in for_each_value_helper()... but only on the final iteration, so even if the ptr was wrong, it didn't matter, as the ptr was never used again. Under certain MSAN configurations, though, the read would be (correctly) flagged as uninitialized.

This fixes the MSAN bug, and also (slightly) improves the efficiency by returning the post-flattened number of dimensions, potentially reducing the number of iterations f for_each_value_helper() needed.
Copy link

@vitalybuka vitalybuka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added few comments, but I know nothing about this code.

The patch fixes sanitizer issue we had.

@@ -2235,26 +2239,30 @@ class Buffer {
}
}

return innermost_strides_are_one;
return {d, innermost_strides_are_one};

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this d can be after d-- on 2226, is this expected?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is deliberate; if we 'flatten' multiple dimensions into one, we want to know the new, smaller number of dimensions.

@@ -2219,7 +2223,7 @@ class Buffer {
}
if (flat) {
t[i - 1].extent *= t[i].extent;
for (int j = i; j < d; j++) {
for (int j = i; j < d - 1; j++) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

t[d-1].extent will be set on line 2231, what is about .stride?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we want to leave that alone -- @abadams to confirm.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need to set the extent, given that we're not going to iterate over that dimension?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oooh, good point. We can probably elide that now. Let me do some hackery to verify.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, that was definitely unnecessary.

@steven-johnson
Copy link
Contributor Author

I now have another thing I'm not sure is optimal; this section in for_each_value_prep():

        bool innermost_strides_are_one = true;
        if (dimensions > 0) {
            for (int i = 0; i < N; i++) {
                innermost_strides_are_one &= (t[0].stride[i] == 1);
            }
        }

I presume the if (dimensions > 0) check is just for paranoia? Currently this function should never be called when dimensions == 0 (there's only one caller). I added an assert() to indicate this is expected as an invariant.

@steven-johnson steven-johnson merged commit 35322c3 into main Feb 10, 2023
@steven-johnson steven-johnson deleted the srj/buf-uninit-stride branch February 10, 2023 00:22
ardier pushed a commit to ardier/Halide-mutation that referenced this pull request Mar 3, 2024
…alide#7330)

* Fix a subtle uninitialized-memory-read in Buffer::for_each_value()

When we flattened dimensions in for_each_value_prep(), we would copy from one past the end, meaning the last element contained uninitialized garbage. (This wasn't noticed as an out-of-bounds read because we overallocated in structure in for_each_value_impl()). This garbage stride was later used to advance ptrs in for_each_value_helper()... but only on the final iteration, so even if the ptr was wrong, it didn't matter, as the ptr was never used again. Under certain MSAN configurations, though, the read would be (correctly) flagged as uninitialized.

This fixes the MSAN bug, and also (slightly) improves the efficiency by returning the post-flattened number of dimensions, potentially reducing the number of iterations f for_each_value_helper() needed.

* Oopsie

* Update HalideBuffer.h

* Update HalideBuffer.h
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants