openSUSE has issued an advisory on July 5: https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/message/KB5WTHV4QSRRUVG6KMSV4Z2FIQKSWR54/
Debian has issued an advisory on June 26: https://lists.debian.org/debian-security-announce/2025/msg00115.html
Whiteboard: (none) => MGA9TOOCVE: (none) => CVE-2025-5222Source RPM: (none) => icu-76.1-2.mga10.src.rpm, icu-73.2-1.mga9.src.rpm
https://github.com/unicode-org/icu/commit/2c667e31cfd0b6bb1923627a932fd3453a5bac77 is the patch from upstream. Unsure what version it applies to; both? Assigning globally.
Assignee: bugsquad => pkg-bugsStatus comment: (none) => upstream patch available
Assignee: pkg-bugs => j.alberto.vc
(In reply to Lewis Smith from comment #2) > https://github.com/unicode-org/icu/commit/ > 2c667e31cfd0b6bb1923627a932fd3453a5bac77 > > is the patch from upstream. Unsure what version it applies to; both? > Assigning globally. Look so, building now
RPMS; icu-73.2-1.2.mga9 icu-doc-73.2-1.2.mga9 icu73-data-73.2-1.2.mga9 lib(64(icu-devel-73.2-1.2.mga9 lib(64)icu73-73.2-1.2.mga9 SRPM: icu-73.2-1.2.mga9
Whiteboard: MGA9TOO => (none)Version: Cauldron => 9Source RPM: icu-76.1-2.mga10.src.rpm, icu-73.2-1.mga9.src.rpm => icu-73.2-1.mga9Assignee: j.alberto.vc => qa-bugs
RPMS: lib(64)wx_baseu3.2_0-3.2.8.1-1.mga9 lib(64)wx_baseu_net3.2_0-3.2.8.1-1.mga9 lib(64)wx_baseu_xml3.2_0-3.2.8.1-1.mga9 lib(64)wx_gtk3u_adv3.2_0-3.2.8.1-1.mga9 lib(64)wx_gtk3u_aui3.2_0-3.2.8.1-1.mga9 lib(64)wx_gtk3u_core3.2_0-3.2.8.1-1.mga9 lib(64)wx_gtk3u_gl3.2_0-3.2.8.1-1.mga9 lib(64)wx_gtk3u_html3.2_0-3.2.8.1-1.mga9 lib(64)wx_gtk3u_media3.2_0-3.2.8.1-1.mga9 lib(64)wx_gtk3u_propgrid3.2_0-3.2.8.1-1.mga9 lib(64)wx_gtk3u_qa3.2_0-3.2.8.1-1.mga9 lib(64)wx_gtk3u_ribbon3.2_0-3.2.8.1-1.mga9 lib(64)wx_gtk3u_richtext3.2_0-3.2.8.1-1.mga9 lib(64)wx_gtk3u_stc3.2_0-3.2.8.1-1.mga9 lib(64)wx_gtk3u_webview3.2_0-3.2.8.1-1.mga9 lib(64)wx_gtk3u_xrc3.2_0-3.2.8.1-1.mga9 lib(64)wxgtku3.2-devel-3.2.8.1-1.mga9 wxgtk3.2-3.2.8.1-1.mga9 SRPM: wxgtk-3.2.8.1-1.mga9
Ups sorry
Keywords: (none) => advisory
Blocks: (none) => 34447
RH x86_64 installing icu73-data-73.2-1.2.mga9.noarch.rpm lib64icu73-73.2-1.2.mga9.x86_64.rpm from //home/katnatek/qa-testing/x86_64 Preparing... ################################################################################################## 1/2: icu73-data ################################################################################################## 2/2: lib64icu73 ################################################################################################## 1/2: removing lib64icu73-1:73.2-1.mga9.x86_64 ################################################################################################## 2/2: removing icu73-data-1:73.2-1.mga9.noarch ################################################################################################## strace poedit file.po shows openat(AT_FDCWD, "/lib64/libicui18n.so.73", O_RDONLY|O_CLOEXEC) = 3 strace guayadeque shows openat(AT_FDCWD, "/lib64/libicuuc.so.73", O_RDONLY|O_CLOEXEC) = 3 strace aegisub shows (need check in wayland too) openat(AT_FDCWD, "/lib64/libicuuc.so.73", O_RDONLY|O_CLOEXEC) = 3 Looks good for me
MGA9-64 server Plasma Wayland on Compaq H000SB N onstallation issues. Ref bug 29491 for testing. $ icuinfo <icuSystemParams type="icu4c"> <param name="copyright"> Copyright (C) 2016 and later: Unicode, Inc. and others. License & terms of use: http://www.unicode.org/copyright.html </param> <param name="product">icu4c</param> <param name="product.full">International Components for Unicode for C/C++</param> <param name="version">73.2</param> etc.... </icuSystemParams> ICU Initialization returned: U_ZERO_ERROR Plugins are disabled. $ uconv --list UTF-8 ibm-1208 ibm-1209 ibm-5304 ibm-5305 ibm-13496 ibm-13497 ibm-17592 ibm-17593 windows-65001 cp1208 x-UTF_8J unicode-1-1-utf-8 unicode-2-0-utf-8 UTF-16 ISO-10646-UCS-2 ibm-1204 ibm-1205 unicode csUnicode ucs-2 and a loooong list, ending with ibm-16804_X110-1999,swaplfnl ibm-16804-s390 ebcdic-xml-us $ uconv --default-code UTF-8 $ uconv -f UTF-8 -t SJIS -o icu.txt createtriggerafterupdate.txt $ diff icu.txt createtriggerafterupdate.txt $ uconv -f SJIS -t ISO-8859-1 -o icuiso.txt createtriggerafterupdate.txt $ diff icuiso.txt createtriggerafterupdate.txt $ diff icu.txt icuiso.txt $ No differences found $ cat > part2 π = 3.14159 or thereabouts $ cat > part3 �� = 3.14159 or thereabouts $ file part3 part3: Unicode text, UTF-8 text, with no line terminators $ uconv -f UTF-8 -t ISO-8859-1 -o part4 part2 Conversion from Unicode to codepage failed at input byte position 0. Unicode: 03c0 Error: Invalid character found $ od -x part2 0000000 80cf 3d20 3320 312e 3134 3935 6f20 2072 0000020 6874 7265 6165 6f62 7475 0073 0000033 $ od -x part3 0000000 bfef efbd bdbf 3d20 3320 312e 3134 3935 0000020 6f20 2072 6874 7265 6165 6f62 7475 0073 0000037 That's as far as I go, but it all seems reasonable. Tx Len
Whiteboard: (none) => MGA9-64-OKCC: (none) => herman.viaene
Validating.
CC: (none) => andrewsfarm
Really validating this time. This update will cause a rebuild of a long list of packages (See Bug 33553) so it should not be pushed until that is taken care of.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
CC: (none) => danDepends on: (none) => 33553
Depends on: 33553 => (none)
I want to handle here the packages that need to rebuild List of SRPMS: https://bugs.mageia.org/attachment.cgi?id=14663
Summary: icu new security issue CVE-2025-5222 => icu new security issue CVE-2025-5222 & packages need to be rebuild
Assignee: qa-bugs => pkg-bugsWhiteboard: MGA9-64-OK => (none)Keywords: validated_update => (none)
(In reply to katnatek from comment #11) > I want to handle here the packages that need to rebuild > > List of SRPMS: > https://bugs.mageia.org/attachment.cgi?id=14663 If can provide of build order please
I wonder if the mass build script could be used to this type of work?
I did try to get a build order with https://hackage.haskell.org/package/rpmbuild-order from fedora, but not likes our boost spec https://copr.fedorainfracloud.org/coprs/katnatek/mgaMentorship/build/9343334/
Blocks: 34447 => (none)
Depends on: (none) => 34619
Depends on: (none) => 33513
Depends on: (none) => 34665
Thomas & Dan if is fine for both can we validate & push this packages I will keep working on the rebuild of packages still requiring icu. So not see why not push a security update.
Assignee: pkg-bugs => qa-bugsDepends on: 33513, 34619, 34665 => (none)
Summary: icu new security issue CVE-2025-5222 & packages need to be rebuild => icu new security issue CVE-2025-5222
I really don't know enough to object, or not, so I'll go along with what those who know better decide.
Whiteboard: (none) => MGA9-64-OKKeywords: (none) => validated_update
Blocks: (none) => 34619
I've pushed this since it's a valid update (but I probably pushed it prematurely). However, I noticed that I still have the old, vulnerable lib64icu72 on my system, but removing it would remove over 1800 packages. It looks like when icu73 was pushed (in bug 33553) all its dependencies were not updated, meaning that icu72 and icu73 now live side-by-side in mga9. That, in turn, means that security updates to icu72 still need to be provided as well as to icu73.
Status: NEW => ASSIGNED
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2025-0249.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
Reopened to handle icu72 (comment 17).
Resolution: FIXED => (none)Status: RESOLVED => REOPENED
I've discovered bug 34619 and 34665 which are to rebuild all packages depending on icu. Either that needs to be done and all those packages pushed, or icu72 should be patched. Or both; patching icu72 now then pushing those packages later.
(In reply to Dan Fandrich from comment #20) > I've discovered bug 34619 and 34665 which are to rebuild all packages > depending on icu. Either that needs to be done and all those packages > pushed, or icu72 should be patched. Or both; patching icu72 now then pushing > those packages later. I think as the first is WIP and already some QA is done the other will produce duplication of work I'm worried about bug#33513 and bug#34672, but if not exist packages for samba when finish the list of stage 2 and not see intentions to fix webkit2 when reach stage 3, I'm just make a rebuild
It may be duplication of work to patch icu72, but since those rebuilds haven't been done after over 13 months, fixing the security issue now a single patch seems more prudent than waiting an indeterminate time for rebuilds.
(In reply to Dan Fandrich from comment #22) > It may be duplication of work to patch icu72, but since those rebuilds > haven't been done after over 13 months, fixing the security issue now a > single patch seems more prudent than waiting an indeterminate time for > rebuilds. Exist other problem with the idea of patch icu 72, icu 73 comes from icu srpm, so not exist icu72/icu73 separation in terms of srpm/svn , so will need to create icu72 srpm to do that as work from icu will be rejected by the BS if we send a build for version 72 So I think we not have other choice to keep working in the rebuild of packages for icu73 even if that will delay more
Ok, I'll continue the conversation in those two bugs.
Resolution: (none) => FIXEDStatus: REOPENED => RESOLVED