[Medium] Patch mysql for CVE-2025-0838#15867
Conversation
|
Buddy Build has been triggered - https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1050450&view=results |
|
as the ptest is known failure and we have skipped it in 2.0 as well. Can you skip it here as well? Even fedora has skipped the tests. |
|
|
After skipping the known failure cases - https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1050530&view=results |
The Buddy Build has passed on arm64 but failed on amd64 due to test case failure. The test cases which are getting failed are similar to the ones which were failed in the 1st Buddy Build, although SPEC file is updated as per 2.0 branch. I am looking into it. |
Till now my observations are as follows -
Now I am investigating, how these test cases are getting passed on 2.0 branch, but getting failed here on 3.0 branch. |
|
Buddy Build has failed again and similar cases failing here as well when compared to 2nd Buddy build. Although when I tried to build locally using containerized rpm build for mysql with latest spec file, only 3 cases were getting failed due to timeout and other reasons. I am looking into it. |
b8b9a65 to
a8204ca
Compare
|
Buddy Build has been triggered again - https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1058494&view=results |
The latest buddy build has failed due to some dead code related to GTEST is present in the file, from where the ptests have been removed. Once the dead code is removed, the Buddy build will pass. Patch file need to be updated. Kindly note, that no such issues came while executing containerized RPM build locally. |
|
Again, triggered the Buddy Build - https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1061155&view=results |
The latest Buddy Build has passed. |
|
Again, triggered the Buddy Build with updated patch file - https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1063464&view=results |
The Buddy Build has failed due to reasons unrelated to this PR. All the Buddy builds which have been triggered today, have same issue. It has to be re-triggered once the Buddy Build issue is resolved. |
| size_t capacity() const { return common().capacity(); } | ||
| - size_t max_size() const { return (std::numeric_limits<size_t>::max)(); } | ||
| + size_t max_size() const { | ||
| + return CapacityToGrowth(MaxValidCapacity<sizeof(slot_type)>()); |
kgodara912
left a comment
There was a problem hiding this comment.
Please don't skip test cases which are only failing for one architecture instead, the tests can be conditionally included or excluded. Only large tests was the one which was having issue. Include other test for arm testing. You may apply changes conditionally based on arch, so when arch is not x86, then don't apply the patch so all other architectures can be tested.
Sure, I will update the spec file accordingly and confirm. |
|
Updated the spec file. |
Hi @kgodara912 |
kgodara912
left a comment
There was a problem hiding this comment.
Upstream patch is backported with adaptation to the existing version. Buddy build is successful. The test failures were specific to x86 and are addressed in this along with flaky merge_large_tests test . LGTM.
Merge Checklist
All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)
*-staticsubpackages, etc.) have had theirReleasetag incremented../cgmanifest.json,./toolkit/scripts/toolchain/cgmanifest.json,.github/workflows/cgmanifest.json)./LICENSES-AND-NOTICES/SPECS/data/licenses.json,./LICENSES-AND-NOTICES/SPECS/LICENSES-MAP.md,./LICENSES-AND-NOTICES/SPECS/LICENSE-EXCEPTIONS.PHOTON)*.signatures.jsonfilessudo make go-tidy-allandsudo make go-test-coveragepassSummary
Patch mysql for CVE-2025-0838
ABSL_SWISSTABLE_ASSERTmacro, referred upstream source.SlotOffset()has been used in place ofslot_offset_from upstream patch, as its already being used in the current source.Change Log
Does this affect the toolchain?
NO
Links to CVEs
Test Methodology