Fedora has issued an advisory on July 9: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/OQRAHYHLRNMBTPR3KXVM27NSZP3KTOPI/ The issue is fixed upstream in 10.34 (newest is 10.35).
This pkg is maintained by different people, so assigning the bug globally.
Assignee: bugsquad => pkg-bugs
Suggested advisory: ======================== The updated packages fix a security vulnerability: An out-of-bounds read was discovered in PCRE before 10.34 when the pattern \X is JIT compiled and used to match specially crafted subjects in non-UTF mode. Applications that use PCRE to parse untrusted input may be vulnerable to this flaw, which would allow an attacker to crash the application. The flaw occurs in do_extuni_no_utf in pcre2_jit_compile.c. (CVE-2019-20454) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-20454 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/OQRAHYHLRNMBTPR3KXVM27NSZP3KTOPI/ ======================== Updated packages in core/updates_testing: ======================== lib(64)pcre2_0-10.33-1.2.mga7 lib(64)pcre2posix2-10.33-1.2.mga7 lib(64)pcre2-devel-10.33-1.2.mga7 pcre2-tools-10.33-1.2.mga7 from SRPMS: pcre2-10.33-1.2.mga7.src.rpm
Status: NEW => ASSIGNEDCC: (none) => nicolas.salgueroAssignee: pkg-bugs => qa-bugsCVE: (none) => CVE-2019-20454
mga7, x86_64 CVE-2019-20454 https://bugzilla.redhat.com/show_bug.cgi?id=1734468 $ printf '%s\n%s\n' '/\X*/' '\xF3aaa\xE4\xEA\xEB\xFEa' | pcre2test -jit PCRE2 version 10.33 2019-04-16 /\X*/ \xF3aaa\xE4\xEA\xEB\xFEa Segmentation fault (core dumped) Updated the four packages. $ printf '%s\n%s\n' '/\X*/' '\xF3aaa\xE4\xEA\xEB\xFEa' | pcre2test -jit PCRE2 version 10.33 2019-04-16 /\X*/ \xF3aaa\xE4\xEA\xEB\xFEa 0: \xf3aaa\xe4\xea\xeb\xfea Confirms that the patch works. Several applications use libpcre2 including fish, godot and php-cli. Provided utilities: $ pcre2test -C PCRE2 version 10.33 2019-04-16 Compiled with 8-bit support 16-bit support 32-bit support UTF and UCP support (Unicode version 11.0.0) Just-in-time compiler support: x86 64bit (little endian + unaligned) Newline sequence is LF \R matches all Unicode newlines \C is supported Internal link size = 2 Parentheses nest limit = 250 Default heap limit = 20000000 kibibytes Default match limit = 10000000 Default depth limit = 10000000 Many listed by the man command do not seem to be installed. pcre2-config and pcre2grep are provided. Made a copy of one of my bin files and tried grep: $ pcre2grep -u notebook ~/bin/notebook homefile = Dir.home + "/pad/notebook/" puts "Creating dummy resource file notebook.rc" resource = homefile + "notebook.rc" puts "Cannot create notebook.rc for user" #puts "notebook: notefile is #{notefile}" # than defaulting to localhost. It is used in the naming of notebooks to # distinguish imported notebooks from native ones. @target.value = ::Share+"notebook/note.dump" filename = "/tmp/notebook-#{ref}" $ pcre2grep -u -v -t notebook ~/bin/notebook 1193 $ pcre2grep -u -t notebook ~/bin/notebook 9 $ lines notebook 1202 $ diff notebook ~/bin/notebook $ That is odd. It implies that the cp operation changed something hidden. However, the files sizes agree. $ ll notebook bin/notebook -rwxr-xr-x 1 lcl lcl 37991 Sep 27 2019 bin/notebook* -rwxr-xr-x 1 lcl lcl 37991 Jul 21 07:45 notebook* Back to this later.
CC: (none) => tarazed25
Barking up the wrong tree. $ pcre2grep -u -t notebook ~/bin/notebook works like $ grep notebook ~/bin/notebook | wc -l 9 Ran godot under strace. Started a project, browsed asset lib, downloaded and installed an item from the library. $ grep pcre2 trace.godot openat(AT_FDCWD, "/lib64/libpcre2-32.so.0", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib64/libpcre2-32.so.0.8.0", O_RDONLY) = 3 openat(AT_FDCWD, "/usr/lib64/libpcre2-32.so.0.8.0", O_RDONLY) = 4 which shows that lib64pcre2_0 is being accessed. $ pcre2grep -a -c coordinates /bin/stellarium 18 $ strings /bin/stellarium | grep coordinates | wc -l 50 This difference is understandable because strings searches for individual instances of the text whereas pcre2 returns the number of lines in which the text matches, where "lines" is a moveable feast (occur only accidentally in binary files). $ pcre2grep --files-with-matches widgetlist *.rb bax.rb bookshelf.rb bugcentre.rb [...] synciso.rb totals.rb vbox.rb youwhat.rb $ grep widgetlist bugcentre.rb require Dir.home+'/ruby/local/widgetlist' $ grep widgetlist synciso.rb require Dir.home+'/ruby/local/widgetlist' Not delving any deeper with this. pcre2 works at a basic level.
Whiteboard: (none) => MGA7-64-OK
Validating. Advisory in Comment 2.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
CC: (none) => davidwhodginsKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0305.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED