Prevent signed integer overflow in pixel_shuffle size calculation by GregoryComer · Pull Request #16138 · pytorch/executorch

GregoryComer · 2025-12-09T00:32:33Z

Summary:
The size calculation in get_pixel_shuffle_out_target_size can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing.

Specifically, the calculation of upscale_factor * upscale_factor (source) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17.

Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in check_pixel_shuffle_args and also assert in get_pixel_shuffle_out_target_size to ensure we don't hit UB.

Differential Revision: D88693324

pytorch-bot · 2025-12-09T00:32:37Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit e879e0a with merge base 04f1e4d ():

UNSTABLE - The following job is marked as unstable, possibly due to flakiness on trunk:

pull / android / run-emulator (gh) (#16137)
Timeout waiting for emulator to boot.

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

meta-codesync · 2025-12-09T00:32:40Z

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

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. Differential Revision: D88693324

meta-codesync · 2025-12-09T01:46:12Z

@GregoryComer has imported this pull request. If you are a Meta employee, you can view this in D88693324.

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in `check_pixel_shuffle_args` and also assert in `get_pixel_shuffle_out_target_size` to ensure we don't hit UB. Differential Revision: D88693324

GregoryComer · 2025-12-09T00:32:33Z

Summary:
The size calculation in get_pixel_shuffle_out_target_size can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing.

Specifically, the calculation of upscale_factor * upscale_factor (source) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17.

Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in check_pixel_shuffle_args and also assert in get_pixel_shuffle_out_target_size to ensure we don't hit UB.

Differential Revision: D88693324

pytorch-bot · 2025-12-09T00:32:37Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit e879e0a with merge base 04f1e4d ():

UNSTABLE - The following job is marked as unstable, possibly due to flakiness on trunk:

pull / android / run-emulator (gh) (#16137)
Timeout waiting for emulator to boot.

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

meta-codesync · 2025-12-09T00:32:40Z

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

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. Differential Revision: D88693324

meta-codesync · 2025-12-09T01:46:12Z

@GregoryComer has imported this pull request. If you are a Meta employee, you can view this in D88693324.

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in `check_pixel_shuffle_args` and also assert in `get_pixel_shuffle_out_target_size` to ensure we don't hit UB. Differential Revision: D88693324

GregoryComer · 2025-12-09T00:32:33Z

Summary:
The size calculation in get_pixel_shuffle_out_target_size can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing.

Specifically, the calculation of upscale_factor * upscale_factor (source) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17.

Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in check_pixel_shuffle_args and also assert in get_pixel_shuffle_out_target_size to ensure we don't hit UB.

Differential Revision: D88693324

pytorch-bot · 2025-12-09T00:32:37Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit e879e0a with merge base 04f1e4d ():

UNSTABLE - The following job is marked as unstable, possibly due to flakiness on trunk:

pull / android / run-emulator (gh) (#16137)
Timeout waiting for emulator to boot.

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

meta-codesync · 2025-12-09T00:32:40Z

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

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. Differential Revision: D88693324

meta-codesync · 2025-12-09T01:46:12Z

@GregoryComer has imported this pull request. If you are a Meta employee, you can view this in D88693324.

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in `check_pixel_shuffle_args` and also assert in `get_pixel_shuffle_out_target_size` to ensure we don't hit UB. Differential Revision: D88693324

GregoryComer · 2025-12-09T00:32:33Z

Summary:
The size calculation in get_pixel_shuffle_out_target_size can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing.

Specifically, the calculation of upscale_factor * upscale_factor (source) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17.

Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in check_pixel_shuffle_args and also assert in get_pixel_shuffle_out_target_size to ensure we don't hit UB.

Differential Revision: D88693324

pytorch-bot · 2025-12-09T00:32:37Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit e879e0a with merge base 04f1e4d ():

UNSTABLE - The following job is marked as unstable, possibly due to flakiness on trunk:

pull / android / run-emulator (gh) (#16137)
Timeout waiting for emulator to boot.

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

meta-codesync · 2025-12-09T00:32:40Z

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

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. Differential Revision: D88693324

meta-codesync · 2025-12-09T01:46:12Z

@GregoryComer has imported this pull request. If you are a Meta employee, you can view this in D88693324.

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in `check_pixel_shuffle_args` and also assert in `get_pixel_shuffle_out_target_size` to ensure we don't hit UB. Differential Revision: D88693324

GregoryComer · 2025-12-09T00:32:33Z

Summary:
The size calculation in get_pixel_shuffle_out_target_size can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing.

Specifically, the calculation of upscale_factor * upscale_factor (source) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17.

Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in check_pixel_shuffle_args and also assert in get_pixel_shuffle_out_target_size to ensure we don't hit UB.

Differential Revision: D88693324

pytorch-bot · 2025-12-09T00:32:37Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit e879e0a with merge base 04f1e4d ():

UNSTABLE - The following job is marked as unstable, possibly due to flakiness on trunk:

pull / android / run-emulator (gh) (#16137)
Timeout waiting for emulator to boot.

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

meta-codesync · 2025-12-09T00:32:40Z

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

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. Differential Revision: D88693324

meta-codesync · 2025-12-09T01:46:12Z

@GregoryComer has imported this pull request. If you are a Meta employee, you can view this in D88693324.

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in `check_pixel_shuffle_args` and also assert in `get_pixel_shuffle_out_target_size` to ensure we don't hit UB. Differential Revision: D88693324

GregoryComer · 2025-12-09T00:32:33Z

Summary:
The size calculation in get_pixel_shuffle_out_target_size can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing.

Specifically, the calculation of upscale_factor * upscale_factor (source) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17.

Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in check_pixel_shuffle_args and also assert in get_pixel_shuffle_out_target_size to ensure we don't hit UB.

Differential Revision: D88693324

pytorch-bot · 2025-12-09T00:32:37Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit e879e0a with merge base 04f1e4d ():

UNSTABLE - The following job is marked as unstable, possibly due to flakiness on trunk:

pull / android / run-emulator (gh) (#16137)
Timeout waiting for emulator to boot.

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

meta-codesync · 2025-12-09T00:32:40Z

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

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. Differential Revision: D88693324

meta-codesync · 2025-12-09T01:46:12Z

@GregoryComer has imported this pull request. If you are a Meta employee, you can view this in D88693324.

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in `check_pixel_shuffle_args` and also assert in `get_pixel_shuffle_out_target_size` to ensure we don't hit UB. Differential Revision: D88693324

GregoryComer · 2025-12-09T00:32:33Z

Summary:
The size calculation in get_pixel_shuffle_out_target_size can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing.

Specifically, the calculation of upscale_factor * upscale_factor (source) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17.

Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in check_pixel_shuffle_args and also assert in get_pixel_shuffle_out_target_size to ensure we don't hit UB.

Differential Revision: D88693324

pytorch-bot · 2025-12-09T00:32:37Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit e879e0a with merge base 04f1e4d ():

UNSTABLE - The following job is marked as unstable, possibly due to flakiness on trunk:

pull / android / run-emulator (gh) (#16137)
Timeout waiting for emulator to boot.

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

meta-codesync · 2025-12-09T00:32:40Z

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

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. Differential Revision: D88693324

meta-codesync · 2025-12-09T01:46:12Z

@GregoryComer has imported this pull request. If you are a Meta employee, you can view this in D88693324.

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in `check_pixel_shuffle_args` and also assert in `get_pixel_shuffle_out_target_size` to ensure we don't hit UB. Differential Revision: D88693324

GregoryComer · 2025-12-09T00:32:33Z

Summary:
The size calculation in get_pixel_shuffle_out_target_size can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing.

Specifically, the calculation of upscale_factor * upscale_factor (source) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17.

Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in check_pixel_shuffle_args and also assert in get_pixel_shuffle_out_target_size to ensure we don't hit UB.

Differential Revision: D88693324

pytorch-bot · 2025-12-09T00:32:37Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit e879e0a with merge base 04f1e4d ():

UNSTABLE - The following job is marked as unstable, possibly due to flakiness on trunk:

pull / android / run-emulator (gh) (#16137)
Timeout waiting for emulator to boot.

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

meta-codesync · 2025-12-09T00:32:40Z

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

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. Differential Revision: D88693324

meta-codesync · 2025-12-09T01:46:12Z

@GregoryComer has imported this pull request. If you are a Meta employee, you can view this in D88693324.

…torch#16138) Summary: The size calculation in `get_pixel_shuffle_out_target_size` can trigger signed integer overflow (UB) with very large upscale_factors. This manifested as an integer division by zero fault during fuzzing. Specifically, the calculation of `upscale_factor * upscale_factor` ([source](https://github.com/pytorch/executorch/blob/04f1e4d22383ffcbc770acf5002348e3f95082a2/kernels/portable/cpu/util/copy_ops_util.cpp#L364)) can overflow. In the motivating case, SizesType is a signed 32-bit integer and upscale_factor = 2^17. Since this is an impractically large upscale factor, I'm just adding a constraint that upscale_factor < 32768 (2^15). In theory, SizesType could be defined as less than 32 bits, but this seems unlikely in practice. I check this upper bound in `check_pixel_shuffle_args` and also assert in `get_pixel_shuffle_out_target_size` to ensure we don't hit UB. Differential Revision: D88693324

GregoryComer requested a review from manuelcandales as a code owner December 9, 2025 00:32

meta-claBot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Dec 9, 2025

meta-codesyncBot added fb-exported meta-exported labels Dec 9, 2025

GregoryComer requested review from JacobSzwejbka and larryliu0820 December 9, 2025 00:36

GregoryComer added the release notes: none Do not include this in the release notes label Dec 9, 2025

JacobSzwejbka approved these changes Dec 9, 2025
View reviewed changes

JacobSzwejbka reviewed Dec 9, 2025
View reviewed changes

Comment threadkernels/portable/cpu/util/copy_ops_util.cpp Outdated

GregoryComer force-pushed the export-D88693324 branch from ae8b60a to d42a11cCompare December 9, 2025 00:49

GregoryComer force-pushed the export-D88693324 branch from d42a11c to e879e0aCompare December 9, 2025 00:53

manuelcandales approved these changes Dec 9, 2025
View reviewed changes

GregoryComer merged commit c9f6df1 into pytorch:mainDec 9, 2025
237 of 246 checks passed