Fedora has issued an advisory today (December 27): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/DJIW6KKY2TSLD43XEZXG56WREIIBUIIQ/ The issues are fixed upstream in 2.35.
Status comment: (none) => Patches available from upstream and Fedora
Patched packages uploaded for Mageia 7. Advisory: ======================== Updated binutils and mingw-binutils packages fixes security vulnerabilities: It was discovered that mingw-binutils and binutils suffered from two vulnerabilites which might lead to DoS. * Null Pointer Dereference in debug_get_real_type could result in DoS (CVE-2020-16598). * use-after-free in bfd_hash_lookup could result in DoS (CVE-2020-16592). References: ======================== https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/DJIW6KKY2TSLD43XEZXG56WREIIBUIIQ/ https://nvd.nist.gov/vuln/detail/CVE-2020-16592 https://nvd.nist.gov/vuln/detail/CVE-2020-16598 Updated packages in core/updates_testing: ======================== binutils-2.33.1-1.1.mga7 lib64binutils-devel-2.33.1-1.1.mga7 from binutils-2.33.1-1.1.mga7.src.rpm mingw32-binutils-2.30-3.1.mga7 mingw64-binutils-2.30-3.1.mga7 mingw-binutils-generic-2.30-3.1.mga7 from mingw-binutils-2.30-3.1.mga7.src.rpm Testing information: https://bugs.mageia.org/show_bug.cgi?id=25298
Assignee: tmb => qa-bugsKeywords: (none) => has_procedureCC: (none) => mrambo
I guess cross-binutils have the same issues
(additional package list to that in comment #1) (In reply to Thomas Backlund from comment #2) Patched cross-binutils package also uploaded for Mageia 7. Updated packages in core/updates_testing: ======================== binutils-aarch64-linux-gnu-2.31.1-1.1.mga7 binutils-alpha-linux-gnu-2.31.1-1.1.mga7 binutils-arc-linux-gnu-2.31.1-1.1.mga7 binutils-arm-linux-gnu-2.31.1-1.1.mga7 binutils-avr32-linux-gnu-2.31.1-1.1.mga7 binutils-bfin-linux-gnu-2.31.1-1.1.mga7 binutils-c6x-linux-gnu-2.31.1-1.1.mga7 binutils-cris-linux-gnu-2.31.1-1.1.mga7 binutils-frv-linux-gnu-2.31.1-1.1.mga7 binutils-h8300-linux-gnu-2.31.1-1.1.mga7 binutils-hppa64-linux-gnu-2.31.1-1.1.mga7 binutils-hppa-linux-gnu-2.31.1-1.1.mga7 binutils-ia64-linux-gnu-2.31.1-1.1.mga7 binutils-m32r-linux-gnu-2.31.1-1.1.mga7 binutils-m68k-linux-gnu-2.31.1-1.1.mga7 binutils-metag-linux-gnu-2.31.1-1.1.mga7 binutils-microblaze-linux-gnu-2.31.1-1.1.mga7 binutils-mips64-linux-gnu-2.31.1-1.1.mga7 binutils-mn10300-linux-gnu-2.31.1-1.1.mga7 binutils-nios2-linux-gnu-2.31.1-1.1.mga7 binutils-openrisc-linux-gnu-2.31.1-1.1.mga7 binutils-powerpc64le-linux-gnu-2.31.1-1.1.mga7 binutils-powerpc64-linux-gnu-2.31.1-1.1.mga7 binutils-ppc64le-linux-gnu-2.31.1-1.1.mga7 binutils-ppc64-linux-gnu-2.31.1-1.1.mga7 binutils-riscv64-linux-gnu-2.31.1-1.1.mga7 binutils-s390x-linux-gnu-2.31.1-1.1.mga7 binutils-score-linux-gnu-2.31.1-1.1.mga7 binutils-sh-linux-gnu-2.31.1-1.1.mga7 binutils-sparc64-linux-gnu-2.31.1-1.1.mga7 binutils-tile-linux-gnu-2.31.1-1.1.mga7 binutils-x86_64-linux-gnu-2.31.1-1.1.mga7 binutils-xtensa-linux-gnu-2.31.1-1.1.mga7 cross-binutils-common-2.31.1-1.1.mga7.noarch.rpm from cross-binutils-2.31.1-1.1.mga7.src.rpm
mga7, x86_64 CVE-2020-16592 https://sourceware.org/bugzilla/show_bug.cgi?id=25823 The PoC for the use-after-free issue requires nm-new which cannot be found here. quote: $ nm-new -C PoC $ nm -C poc_uaf_nm nm: poc_uaf_nm: no symbols $ file poc_uaf_nm poc_uaf_nm: PE Unknown PE signature 0x0 Intel 80386, for MS Windows The downloader claims that it is a DOS executable so I have no confidence in this test. Since this is a 32-bit DOS exe it may need to be run/tested with mingw. CVE-2020-16598 https://sourceware.org/bugzilla/show_bug.cgi?id=25840 $ objdump -g poc_null_objdump poc_null_objdump: file format pei-i386 objdump: parse_coff_type: Bad type code 0x46 : typedef <undefined> *(�) (/* unknown */); typedef void void; void /* 0xffff */; typedef float float; Segmentation fault (core dumped) Updated the packages. - binutils-2.33.1-1.1.mga7.x86_64 - binutils-x86_64-linux-gnu-2.31.1-1.1.mga7.x86_64 - cross-binutils-common-2.31.1-1.1.mga7.noarch - lib64binutils-devel-2.33.1-1.1.mga7.x86_64 - mingw-binutils-generic-2.30-3.1.mga7.x86_64 - mingw64-binutils-2.30-3.1.mga7.x86_64 CVE-2020-16592 $ nm -C poc_uaf_nm nm: poc_uaf_nm: no symbols CVE-2020-16598 $ objdump -g poc_null_objdump poc_null_objdump: file format pei-i386 objdump: parse_coff_type: Bad type code 0x46 : typedef <undefined> *(�) (/* unknown */); typedef void void; void /* 0xffff */; typedef float float; (struct %anon1 { void; /* bitpos 0 */ void <corrupt>; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ float; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ void <corrupt>; /* bitpos 0 */ void <corrupt>; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ (struct %anon2 { void; /* bitpos 0 */ void <corrupt>; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ <undefined>; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ void <corrupt>; /* bitpos 0 */ void <corrupt>; /* bitpos 0 */ void; /* bitpos 0 */ void; /* bitpos 0 */ void ��; /* bitpos 0 */ void; /* bitpos 0 */ }) *; /* bitpos 0 */ }) *|; That looks better. Finishing this later.
CC: (none) => tarazed25
Like next year. CVE-2020-16592 Tried tmb's earlier suggestion about the gold linker - no longer in a position to try the pre-update case yet. $ ld.gold poc_uaf_nm ld.gold: error: poc_uaf_nm:1:3: invalid character ld.gold: error: poc_uaf_nm:1:3: syntax error, unexpected $end ld.gold: error: poc_uaf_nm: not an object or archive Just repeating the tests on the previous bug. $ objdump -x /bin/pulseaudio /bin/pulseaudio: file format elf64-x86-64 /bin/pulseaudio architecture: i386:x86-64, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x0000000000408030 Program Header: PHDR off 0x0000000000000040 vaddr 0x0000000000400040 paddr 0x0000000000400040 align 2**3 [...] 25 .gnu_debugdata 000005e0 0000000000000000 0000000000000000 00016098 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols $ objdump -f /bin/cargo /bin/cargo: file format elf64-x86-64 architecture: i386:x86-64, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x000000000008fbf0 $ readelf -hl /bin/python3 ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V [...] Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt 03 .init .plt .text .fini 04 .rodata .eh_frame_hdr .eh_frame 05 .init_array .fini_array .dynamic .got .got.plt .data .bss 06 .dynamic 07 .note.gnu.build-id .note.ABI-tag 08 .eh_frame_hdr 09 10 .init_array .fini_array .dynamic .got $ nm -A -a -l -S -s --special-syms --synthetic -D /bin/stellarium /bin/stellarium: U acos /bin/stellarium: U acosf /bin/stellarium:00000000005810f0 T acosf@plt /bin/stellarium:0000000000585d30 T acos@plt [...] /bin/stellarium:00000000010f9b60 0000000000000198 u _ZZZN18APIServiceResponse16writeWrappedHTMLERK7QStringS2_ENKUlvE_clEvE15qstring_literal The output actually ran to 1943183 bytes in 21756 lines. $ strings /bin/lua | grep -i luaL luaL_openlib luaL_where luaL_traceback luaL_pushresultsize [...] luaL_unref luaL_buffinit luaL_requiref No regressions for those tests.
Whiteboard: (none) => MGA7-64-OK
Whiteboard: MGA7-64-OK => (none)
Adding this for the sake of completeness. Running on another system before updates: $ ld.gold poc_uaf_nm ld.gold: error: poc_uaf_nm:1:3: invalid character ld.gold: error: poc_uaf_nm:1:3: syntax error, unexpected $end ld.gold: error: poc_uaf_nm: not an object or archive $ mingw-nm -C poc_uaf_nm mingw-nm: poc_uaf_nm: No symbols $ mingw-objdump -g poc_null_objdump poc_null_objdump: file format pei-i386 mingw-objdump: parse_coff_type: Bad type code 0x46 : typedef <undefined> *(�) (/* unknown */); typedef void void; void /* 0xffff */; typedef float float; Segmentation fault (core dumped) After updates: $ mingw-nm -C poc_uaf_nm mingw-nm: poc_uaf_nm: No symbols $ mingw-objdump -g poc_null_objdump poc_null_objdump: file format pei-i386 mingw-objdump: parse_coff_type: Bad type code 0x46 : typedef <undefined> *(�) (/* unknown */); typedef void void; void /* 0xffff */; typedef float float; Segmentation fault (core dumped) So, maybe the cross-compiled packages have not been patched.
Keywords: (none) => feedback
The patches were definitely applied on the box I used to test build the updates. I don't know how to find the build system logs to see what was done there but I wouldn't know why they wouldn't apply there when they did on my system here. Unfortunately this will require someone with a higher level of mastery over this stuff than I possess to decipher what has happened and whether the patches are relevant to the problem.
Where it's built isn't relevant, it's the same sources. I checked your commits and confirmed the patches were applied in the mingw and cross ones. I wouldn't worry too much about mingw stuff...I'm surprised it's even testable. I think we can pass this update.
Whiteboard: (none) => MGA7-64-OKKeywords: feedback => (none)
Thank you for your attention, Gentlemen. Validating. Advisory information in Comment 1 and Comment 3.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
Advisory pushed to SVN.
Status comment: Patches available from upstream and Fedora => (none)CC: (none) => ouaurelienCVE: (none) => CVE-2020-16592, CVE-2020-16598Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0011.html
Status: NEW => RESOLVEDResolution: (none) => FIXED