Fedora has issued an advisory for this on August 17:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/42GU6DEIECFVC2MBUJQ4WYIKXX6GQ3K5/

pushed in updates_testing
src.rpm:
        nasm-2.11.07-2.1.mga5
        nasm-2.12.02-1.1.mga6

Whiteboard: MGA6TOO, MGA5TOO => MGA5TOO
Assignee: tmb => qa-bugs
CC: (none) => mageia
Version: Cauldron => 6

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

Updated nasm packages fix security vulnerabilities:

Multiple heap use after free vulnerabilities (CVE-2017-10686).

Heap-based buffer overflow and application crash (CVE-2017-11111).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-10686
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11111
https://lists.opensuse.org/opensuse-updates/2017-08/msg00030.html
========================

Updated packages in core/updates_testing:
========================
nasm-2.11.07-2.1.mga5
nasm-doc-2.11.07-2.1.mga5
nasm-rdoff-2.11.07-2.1.mga5
nasm-2.12.02-1.1.mga6
nasm-doc-2.12.02-1.1.mga6
nasm-rdoff-2.12.02-1.1.mga6

from SRPMS:
nasm-2.11.07-2.1.mga5.src.rpm
nasm-2.12.02-1.1.mga6.src.rpm

Testing this in mga6 on x86_64.

There are PoC files available, four as I understand it, for CVE-2017-10686 and one for CVE-2017-11111, to be attached.  As usual these are expected to be run with the ASAN framework or using a debugger like gdb.  We shall pass on that.

When run with the command:
$ nasm -f bin POC{1,2,3,4,5} -o nasm.out
they generate core dumps and either abort or segfault and there is no output file.

For CVE-2017-10686:
$ nasm -f bin POC1 -o nasm.out
For CVE-2017-11111:
$ nasm -f bin POC5 -o nasm.out

POC5 is specific to 11111.

After the update the tests each produce a list of warnings and errors and finish without a segfault, abort or core dump.  Again, there is no output file. 

This would seem to endorse the patches.

The only application which uses nasm is the syntax-checker syntactic-nasm and being way out of touch with nasm I must look for a tutorial online.

CC: (none) => tarazed25

Created attachment 9618 [details]
PoC for CVE-2017-10686

Created attachment 9619 [details]
PoC file for CVE-2017-11111

Run this and the other files with a command of this form:
$ $ nasm -f bin POC5 -o nasm.out

'Hello world' program test based on the instructions at http://asmtutor.com.

Compile with
$ nasm -f elf hello.asm
This outputs hello.o
Load it with the elf_i386 option.
$ ld -m elf_i386 hello.o -o helloworld
$ file helloworld
helloworld: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped
$ ./helloworld
Hello World!

It works.  This uses the eax, ebx, ecx, and edx registers and calls libc via the interrupt stack.  The code from the second lesson worked fine as well.

Note for those who might want to pursue nasm as a career.
The link to an example of a linux system call table in the tutorial referenced in comment 7 is corrupt.  A good alternative might be https://filippo.io/linux-syscall-table/

Sorry folks.  Forgot that there was an IDE.
Installed rdoff-nasm and noted that there is are associated utilities called rdfdump, ldrdf, rdx and rdflib with their own man pages and documentation for rdoff in /usr/share/doc/.

Could not figure out how to start the IDE.  Perhaps the collection of utilities is the IDE.

nasm-rdoff updated OK.

Testing on mga5, x86_64
Before the updates:
$ nasm -f bin POC1 -o nasm.out
*** Error in `nasm': corrupted double-linked list: 0x0000000000efda10 ***
and hung.
POC2 and POC3 caused aborts and POC4 segfaulted.

After the updates:
All the PoCs from POC1 to POC5 issued a series of error messages and terminated cleanly.

This vindicates the patches.

Repeated the helloworld compilation and linking tests re comment 7.  The executable files ran fine.

The rdoff documentation is all there and the utilities /bin/{rdfdump,ldrdf,rdx,rdflib}.
$ ls /usr/share/doc/nasm*
/usr/share/doc/nasm:
AUTHORS  CHANGES  internal.doc  LICENSE  README  TODO
/usr/share/doc/nasm-doc:
html/  nasmdoc.ps.bz2  nasmdoc.txt.bz2
/usr/share/doc/nasm-rdoff:
README  v1-v2.txt

This bug could be validated if we are willing to ignore 32-bits.  If not I could do vbox tests later.

Validating with 1 64-bit OK M5 & M6; sterling work Len.
Advisory to do.

Keywords: (none) => validated_update
CC: (none) => lewyssmith, sysadmin-bugs

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

http://advisories.mageia.org/MGASA-2017-0294.html

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