Fix write-heap-buffer-overflow in copy_out

[lucylq]

Summary:

Check that out.nbytes() is at least as large as src.nbytes() to prevent copying beyond the range of src.

Also add a check on dtypes, make sure out and src dtypes are the same. Otherwise we may copy the wrong dtype without conversion.

The crash is a write-heap-buffer-overflow that occurs in the torch::executor::native::copy_out function. The root cause is that the std::memcpy operation in this function does not check if the destination buffer out is large enough to hold the data from the source tensor src. Specifically, the condition internal::sizes_match_ignoring_leading_1s(out.sizes(), src.sizes()) checks if the sizes of out and src match, ignoring any leading dimensions of size 1 in out, but it does not guarantee that out.nbytes() is greater than or equal to src.nbytes().

The patch fixes the crash by adding an additional check out.nbytes() >= src.nbytes() before performing the std::memcpy operation. This ensures that the destination buffer out is large enough to hold the data from src, preventing the buffer overflow.

if (internal::sizes_match_ignoring_leading_1s(out.sizes(), src.sizes()) &&
    src.numel() > 0 && out.nbytes() >= src.nbytes()) {
  std::memcpy(out.mutable_data_ptr(), src.const_data_ptr(), src.nbytes());
}

Other considerations that reviewers should take into account when validating the patch include verifying that the additional check does not introduce any performance regressions and that it correctly handles edge cases, such as when src is empty or when out and src have different data types. Reviewers should also check that the patch does not affect the functionality of the copy_out function in other scenarios. Additionally, it is worth verifying that the fix is consistent with the existing error handling and checking mechanisms in the copy_out function.

NOTE: This diff is entirely auto-generated by LLM-based patch generator.
Reviewer should carefully examine this diff as Lionhead does not guarrantee the
correctnesss of the patch beyond fixing the crash and passing existing tests.
Please commandeer this diff and revise as needed. Our bot does not respond to
comments or revision requests (yet).

Differential Revision: D80885980

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/15584

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 2 New Failures, 4 Unrelated Failures

As of commit cec4b7b with merge base 2f4ad68 ():

NEW FAILURES - The following jobs have failed:

• pull / android / run-emulator (gh)
  The process '/usr/bin/sh' failed with exit code 255
• Test CUDA Builds / test-models-cuda (add) / linux-job (gh)
  RuntimeError: Command docker exec -t 979a31ad1a373dd5281c83c6178208572ad612ab7d46118177817c3fb9f66c78 /exec failed with exit code 1

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• pull / unittest / linux / linux-job (gh) (trunk failure)
  backends/xnnpack/test/recipes/test_xnnpack_recipes.py::TestXnnpackRecipes::test_int8_static_quant_recipe
• pull / unittest / macos / macos-job (gh) (trunk failure)
  backends/xnnpack/test/recipes/test_xnnpack_recipes.py::TestXnnpackRecipes::test_int8_static_quant_recipe
• pull / unittest-editable / linux / linux-job (gh) (trunk failure)
  backends/xnnpack/test/recipes/test_xnnpack_recipes.py::TestXnnpackRecipes::test_int8_static_quant_recipe
• pull / unittest-editable / macos / macos-job (gh) (trunk failure)
  backends/xnnpack/test/recipes/test_xnnpack_recipes.py::TestXnnpackRecipes::test_int8_static_quant_recipe

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[meta-codesync]

@lucylq has exported this pull request. If you are a Meta employee, you can view the originating Diff in D80885980.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[JacobSzwejbka]

@manuelcandales if numel are equal but nbytes isnt then should we be promoting the dtype here? Im not actually sure what copy_ does for mixed dtype?

[lucylq]

@JacobSzwejbka If nbytes isn't equal, it should go into the else statement, which I think handles different dtypes

[lucylq]

@pytorchbot cherry-pick --onto release/1.0 -c critical

[pytorchbot]

Cherry picking #15584

The cherry pick PR is at #15784 and it is recommended to link a critical cherry pick PR with an issue. The following tracker issues are updated:

• [v1.0.1] Release Tracker #15534 (comment)

Details for Dev Infra team

Raised by workflow job