Bug 26932

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 => ASSIGNED
CC: (none) => nicolas.salguero
Assignee: pkg-bugs => qa-bugs
CVE: (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_update
CC: (none) => andrewsfarm, sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2020-0305.html

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED