Repository: opencv
Issue: Buffer overwrite triggered by UMat.copyTo(Mat) on Intel Graphics
Labels: bug,category: ocl,category: 3rdparty

### System Information

OpenCV 4.9.0 - precompiled OpenCV world
Windows 11 22631.3737
Intel(R) Core(TM) Ultra 5 125H 3.60 GHz
Intel(R) Arc(TM) Graphics, driver 31.0.101.5008

### Detailed description

Buffer overwrite during UMat.copyTo(Mat), causing heap corruption later on. The overwrite is at least 40 bytes. I can consistently reproduce it on this one particular system.

**Workaround 1**
Replace this line (see below code snippet):
  pointCloudUMat.copyTo(pointCloudMat)
with
  pointCloudUMat.getMat(ACCESS_READ).copyTo(pointCloudMat)

Debugging OpenCV, I see that the first produces a call to clEnqueuReadBuffer
![umat-copyto-mat-calls-clEnqueuReadBuffer](https://github.com/opencv/opencv/assets/676943/fdcd6332-fb62-4eae-b2ea-d17387cdcd7b)
The latter produces a call to clEnqueueMapBuffer:
![umat-getMat-copyto-mat-calls-clEnqueueMapBuffer](https://github.com/opencv/opencv/assets/676943/17e8a067-d46d-470e-8d9a-0775cf9e74c8)

Note that while debugging, as far as I can tell, all the parameters given to those OpenCL methods seem correct all the time.

**Workaround 2**
Change CV_OPENCL_DATA_PTR_ALIGNMENT to 64 (cache line size, instead of default 16)
The OpenCV AlignedDataPtr class (see first debug screenshot) makes a temp copy if data is not aligned properly.

I don't know where this alignment value of 16 comes from, nor do I know if it is correct or not. The specification (https://registry.khronos.org/OpenCL/sdk/3.0/docs/man/html/alignmentOfDataTypes.html) isn't very enlightening to me. The Intel docs (https://www.intel.com/content/www/us/en/docs/opencl-sdk/developer-guide-processor-graphics/2019-4/mapping-memory-objects.html) recommend page aligned buffers for performance, but don't say anything about other alignment not being supported.

**Notes**
I'm not actually claiming there is a bug in OpenCV, I don't have any evidence for it. It could well be a driver bug too. The only possible OpenCV bug I can think of is that the memory alignment of 16 is incorrect. I hope an OpenCV expert can shed some light on that.

I ran a memory test on this particular hardware to rule out the possibility of malfunctioning memory.


### Steps to reproduce

```
struct PcPointCpp { // 16 bytes in total
  float X;
  float Y;
  float Z;
  ushort Ir;
  ushort Flags;
};

// Regular field in C++
UMat pointCloudUMat;


// C++/CLI in .Net
auto pointCount = width * height;
auto pointArray = gcnew PcPointCpp[pointCount]; // allocate on .Net heap
pin_ptr<PcPointCpp> pointCloudPin = &pointArray[0]; // avoid that GC can move memory around
Mat pointCloudMat(pointCount, sizeof(PcPointCpp), CV_8U, pointCloudPin); // Wrap Mat around .Net memory

// C++
pointCloudUMat.create(pointCloudMat.size(), pointCloudMat.type()); // Init UMat if needed, so it matches Mat
// Run kernel on pointCloudUMat that fills it with data (from some other parameters)
pointCloudUMat.copyTo(pointCloudMat); // Copy back to CPU - this overwrites the .Net buffer from time to time

// Back to C++/CLI
return pointArray; // return array, so it is impossible that it has been garbage collected meanwhile
```

### Issue submission checklist

- [X] I report the issue, it's not a question
- [X] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [ ] I updated to the latest OpenCV version and the issue is still there
- [ ] There is reproducer code and related data files (videos, images, onnx, etc)