I think this is for you, Thierry.

Assignee: bugsquad => thierry.vignaud

openSUSE has issued an advisory on November 13:
https://lists.opensuse.org/opensuse-updates/2019-11/msg00074.html

This fixes a new issue.

Mageia 7 is also affected.

Whiteboard: (none) => MGA7TOO
Summary: gdb new security issue CVE-2018-20657 => gdb new security issues CVE-2018-20657 and CVE-2019-1010180

CVE-2018-20657 is a wontfix from upstream cf https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88539

CC: (none) => mageia

That's why it gets fixed downstream :o)

Patch 137 have been added in mga7 to fix CVE-2019-1010180.

References:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8ff71a9c80cfcf64c54d4ae938c644b1b1ea19fb
https://sourceware.org/bugzilla/show_bug.cgi?id=23657

from: 
gdb-8.2-8.1.mga7


Cauldron is not affected ( gdb 9.1 )

Whiteboard: MGA7TOO => (none)
Version: Cauldron => 7
Assignee: thierry.vignaud => qa-bugs

Well this is strange.  I can't find any evidence that RedHat actually fixed CVE-2018-20657 in their gdb package, even though they issued an advisory for it.  So we'll WONTFIX that.

Summary: gdb new security issues CVE-2018-20657 and CVE-2019-1010180 => gdb new security issue CVE-2019-1010180

Advisory:
========================

Updated gdb packages fix security vulnerability:

Potential buffer overflow when loading ELF sections larger than the file
(CVE-2019-1010180).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1010180
https://lists.opensuse.org/opensuse-updates/2019-11/msg00074.html
========================

Updated packages in core/updates_testing:
========================
gdb-8.2-8.1.mga7
gdb-headless-8.2-8.1.mga7
gdb-gdbserver-8.2-8.1.mga7
gdb-doc-8.2-8.1.mga7
urpmi-debuginfo-install-8.2-8.1.mga7

from gdb-8.2-8.1.mga7.src.rpm

Created attachment 11661 [details]
Extract from a gdb session based on a tutorial.

CC: (none) => tarazed25

mga7, x86_64

CVE-2019-1010180
https://sourceware.org/bugzilla/show_bug.cgi?id=23657
Download objdump.
$ file objdump
objdump: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=357094b1dd59a808b794149f0043d542f2346b7e, with debug_info, not stripped
$ chmod +x objdump
$ gdb objdump
Reading symbols from objdump...done.
(gdb) run
Starting program: /data/qa/gdb/objdump 
Missing separate debuginfos, use: debuginfo-install glibc-2.29-20.mga7.x86_64
Usage: /data/qa/gdb/objdump <option(s)> <file(s)>
 Display information from object <file(s)>.
 At least one of the following switches must be given:
.........................
[Inferior 1 (process 11300) exited with code 02]
(gdb) quit

No segfault or stackdump.

$ gdb --args objdump -a
(gdb) run
Starting program: /data/qa/gdb/objdump -a
Missing separate debuginfos, use: debuginfo-install glibc-2.29-20.mga7.x86_64
/data/qa/gdb/objdump: 'a.out': No such file
[Inferior 1 (process 12315) exited with code 01]
(gdb) quit

$ touch a.out
$ gdb --args ./objdump -r
....
Reading symbols from ./objdump...done.
(gdb) run
Starting program: /data/qa/gdb/objdump -r
Missing separate debuginfos, use: debuginfo-install glibc-2.29-20.mga7.x86_64
[Inferior 1 (process 13983) exited with code 01]
(gdb) quit

The test file is very much larger than the system objdump binary.
$ ll /usr/bin/objdump
-rwxr-xr-x 1 root root 439744 Feb 25 13:59 /usr/bin/objdump*
$ ll objdump
-rwxrwxr-x 1 lcl lcl 6120552 May 25 16:12 objdump*

$ objdump -g objdump
returns pages of information.

So, cannot reproduce the fault here with gdb and valgrind does not object the downloaded objdump.

Going for the update.
All files updated or installed cleanly.

Afterwards gdb observed this for the bad objdump file:
$ gdb --args ./objdump -r
BFD: warning: /data/qa/gdb/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
Reading symbols from ./objdump...done.
(gdb) 

which is encouraging.

The help commands work fine within gdb, "help running" for example.
Not very familiar with gdb here so opted for tutorial mode:
https://www.geeksforgeeks.org/gdb-command-in-linux-with-examples/

$ cat gfg.cpp

#include <iostream> 
#include <stdlib.h> 
#include <string.h> 
using namespace std; 
  
int findSquare(int a) 
{ 
    return a * a; 
} 
  
int main(int n, char** args) 
{ 
    for (int i = 1; i < n; i++)  
    { 
        int a = atoi(args[i]); 
        cout << findSquare(a) << endl; 
    } 
    return 0; 
} 

$ g++ -g -o gfg gfg.cpp

Continuing this as an attachment....

Suffice to say that gdb worked as expected at this elementary level.  Tried a few other commands like 'set args' and 'show args'.

The update is fine as far as this test goes but no attention has been given to gdb-gdbserver.  Leaving it up in the air in case experts want to have a go.

I'm going to validate. If the experts disagree, feel free to change that.

Advisory in Comment 7.

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-0239.html

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