[qt/qt/qtbase]: Summary of bulk changes made

Git repository change summary for qt/qt/qtbase
Pushed by mirror-service into branch 'dev'.
Changed from b0fea7016954821251a7e493c7c3f47a5f013f26 to 49f634414a669d719d2dbb32c039734f6c8e3da5
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit 804bd720494c2aeed6155b017eeae6ccb0e8adf2 by Oliver Wolff on 17/08/2026 at 07:27..
QWindowsOleDataObject::SetData: validate buffer before reading HGLOBAL

GlobalLock() can return nullptr for an invalid handle, and the buffer
from an external OLE source may be smaller than sizeof(DWORD). Validate
the allocation size first and treat a failed lock as a no-op to avoid a
null pointer dereference.

Task-number: QTBUG-148512
Pick-to: 6.12 6.11 6.8
Change-Id: I90b066b021ffc6d69c2e5067a7951925119226ae
Reviewed-by: Morteza Jamshidi <[email protected]>
Reviewed-by: Wladimir Leuschner <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/804bd720494c2aeed6155b017eeae6ccb0e8adf2

Git commit 140420ed9246b5f5372cdcf5f756517156fd0d97 by Oliver Wolff on 17/08/2026 at 07:27..
QWindowsOleEnumFmtEtc::copyFormatEtc: fix DVTARGETDEVICE copy

Several bugs in the ptd copy path: the return value of IMalloc::Alloc()
was discarded, leaving dest->ptd as a shallow copy of src->ptd and the
new allocation leaked; and tdSize from external OLE data was used
without checking it is at least sizeof(DVTARGETDEVICE), which could
allow a memcpy into a too-small allocation.

copyFormatEtc() also left dest->ptd aliasing src->ptd whenever it
returned false, since the struct is copied wholesale before the ptd
handling runs. QWindowsOleEnumFmtEtc::Next() ignored that return value,
so on failure it handed a FORMATETC with an aliased ptd to external OLE
clients, which then free()'d the same pointer QWindowsOleEnumFmtEtc
frees again in its destructor, causing a double free/use-after-free.
Null out dest->ptd on every failure path and make Next() check the
return value and abort the enumeration with E_OUTOFMEMORY instead.

Task-number: QTBUG-148512
Pick-to: 6.12 6.11 6.8
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Change-Id: I6377c1f48ea43f4cc06dec866368e0f9711dd735
Reviewed-by: Wladimir Leuschner <[email protected]>
Reviewed-by: Morteza Jamshidi <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/140420ed9246b5f5372cdcf5f756517156fd0d97

Git commit 611b94ccb9734d729e8005ff3f91d2d65e0c711d by Laszlo Agocs on 17/08/2026 at 07:34..
rhi: d3d12: Filter out the depth-stencil clear value mismatch warning

The optimized clear value of depth-stencil buffers and textures is
always depth 1.0 and stencil 0, whereas the value the render pass clears
to is up to the application. When they differ, the debug layer says
"ID3D12CommandList::ClearDepthStencilView: The clear values do not match
those passed to resource creation. ..."

This was visible e.g. in the qcrhiplumbing autotest of Qt Canvas
Painter, which clears depth to 0 (not 1) in order to test depth testing.

There is no way of knowing the clear value upfront, which is why the
color counterpart of this message is already suppressed. Do the same for
the depth-stencil one.

Pick-to: 6.12
Change-Id: Ifc11425642cabec8a1f4a3200a2e87e7495c4494
Reviewed-by: Andy Nichols <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/611b94ccb9734d729e8005ff3f91d2d65e0c711d

Git commit 49f634414a669d719d2dbb32c039734f6c8e3da5 by Laszlo Agocs on 17/08/2026 at 07:34..
rhi: d3d12: Discard the mip levels before generating them

The subresources of a placed resource must be initialized with a
Discard, Clear, or Copy operation before they can be used for anything
else. The mipmap generators write the levels above 0 via unordered
access views, which is none of those, so sampling a texture that has
both the render target and the generate mipmaps flags set makes the
debug layer complain with

"Placed resources, reserved resources, or committed resources with
D3D12_HEAP_FLAG_CREATE_NOT_ZEROED flag with either render target or
depth stencil flags must be initialized with a Discard/Clear/Copy
operations before other operations are supported. ..."

This was visible e.g. in the qcrhiplumbing autotest of Qt Canvas
Painter, with one message for each mip level of the offscreen canvas
texture. A Qt Quick item with layer.enabled and layer.mipmap set hits it
as well.

Fix it by discarding the levels above 0 upfront, once for each. Level 0
is left alone, its contents have to be preserved.

The bit array tracking this is now shared with the resolve destination
discarding added in c13fd99f923c90c28e8cea23719bce119dd13fab, since both
track whether a subresource has been initialized, and the two sets can
overlap.

Pick-to: 6.12
Change-Id: Iea3ca72ee101902a93d3152c76a07515fb92093c
Reviewed-by: Andy Nichols <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/49f634414a669d719d2dbb32c039734f6c8e3da5