Hi. I decided to look into upgrading the x264 package, but it needs nasm-2.13 so I hacked it together and made sure it worked locally and compiled fine in mock. Also had to patch their psfonts.ph file to use a different font. See attached svn diff patch. Cheers, Stig
Created attachment 9896 [details] nasm-2.13.02 patch
A couple of comments... - first off, if a patch is merged/obsolete, dont comment it out with a #, just remove them. - same goes for changes in filelists and and other stuff removed upstream, dont comment it, just remove it... that's why we use a VCS ... Also, you didn't attach your new patch
Good morning. Thanks for the corrections. I commented them out because the package is yours and wanted you to see what was done. If it's OK with you, can I commit these changes to SVN? Or do you want another patch? Thanks. Cheers, Stig
Created attachment 9897 [details] Updated patch for nasm 2.13.02
Created attachment 9898 [details] Switch font for nasmdoc patch
Fedora has issued an advisory today (January 16): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/YYKNGOT2RJPJMYLAHG6PJXH5QXLSTVMY/ Updating to this version fixed several security issues. Mageia 5 and Mageia 6 are also affected.
Whiteboard: (none) => MGA6TOOSummary: Update request: nasm-2.13.02 => Update request: nasm-2.13.02 (fixes CVE-2017-1781[0-9] and CVE-2017-17820)QA Contact: (none) => securityComponent: RPM Packages => Security
Status comment: (none) => Fixed upstream in 2.13.02
Advisory: ======================== Security fixes for CVE-2017-17810 CVE-2017-17811 CVE-2017-17812 CVE-2017-17813 CVE-2017-17814 CVE-2017-17815 CVE-2017-17816 CVE-2017-17817 CVE-2017-17818 CVE-2017-17819 CVE-2017-17820 In Netwide Assembler (NASM) 2.14rc0, there is a "SEGV on unknown address" that will cause a remote denial of service attack, because asm/preproc.c mishandles macro calls that have the wrong number of arguments. In Netwide Assembler (NASM) 2.14rc0, there is a heap-based buffer overflow that will cause a remote denial of service attack, related to a strcpy in paste_tokens in asm/preproc.c, a similar issue to CVE-2017-11111. In Netwide Assembler (NASM) 2.14rc0, there is a heap-based buffer over-read in the function detoken() in asm/preproc.c that will cause a remote denial of service attack. In Netwide Assembler (NASM) 2.14rc0, there is a use-after-free in the pp_list_one_macro function in asm/preproc.c that will cause a remote denial of service attack, related to mishandling of line-syntax errors. In Netwide Assembler (NASM) 2.14rc0, there is a use-after-free in do_directive in asm/preproc.c that will cause a remote denial of service attack. In Netwide Assembler (NASM) 2.14rc0, there is an illegal address access in is_mmacro() in asm/preproc.c that will cause a remote denial of service attack, because of a missing check for the relationship between minimum and maximum parameter counts. In Netwide Assembler (NASM) 2.14rc0, there is a use-after-free in pp_getline in asm/preproc.c that will cause a remote denial of service attack. In Netwide Assembler (NASM) 2.14rc0, there is a use-after-free in pp_verror in asm/preproc.c that will cause a remote denial of service attack. In Netwide Assembler (NASM) 2.14rc0, there is a heap-based buffer over-read that will cause a remote denial of service attack, related to a while loop in paste_tokens in asm/preproc.c. In Netwide Assembler (NASM) 2.14rc0, there is an illegal address access in the function find_cc() in asm/preproc.c that will cause a remote denial of service attack, because pointers associated with skip_white_ calls are not validated. In Netwide Assembler (NASM) 2.14rc0, there is a use-after-free in pp_list_one_macro in asm/preproc.c that will lead to a remote denial of service attack, related to mishandling of operand-type errors. References: https://nvd.nist.gov/vuln/detail/CVE-2017-17810 https://nvd.nist.gov/vuln/detail/CVE-2017-17811 https://nvd.nist.gov/vuln/detail/CVE-2017-17812 https://nvd.nist.gov/vuln/detail/CVE-2017-17813 https://nvd.nist.gov/vuln/detail/CVE-2017-17814 https://nvd.nist.gov/vuln/detail/CVE-2017-17815 https://nvd.nist.gov/vuln/detail/CVE-2017-17816 https://nvd.nist.gov/vuln/detail/CVE-2017-17817 https://nvd.nist.gov/vuln/detail/CVE-2017-17818 https://nvd.nist.gov/vuln/detail/CVE-2017-17819 https://nvd.nist.gov/vuln/detail/CVE-2017-17820 https://bugzilla.nasm.us/show_bug.cgi?id=3392431 https://bugzilla.nasm.us/show_bug.cgi?id=3392432 https://bugzilla.nasm.us/show_bug.cgi?id=3392424 https://bugzilla.nasm.us/show_bug.cgi?id=3392429 https://bugzilla.nasm.us/show_bug.cgi?id=3392430 https://bugzilla.nasm.us/show_bug.cgi?id=3392436 https://bugzilla.nasm.us/show_bug.cgi?id=3392426 https://bugzilla.nasm.us/show_bug.cgi?id=3392427 https://bugzilla.nasm.us/show_bug.cgi?id=3392428 https://bugzilla.nasm.us/show_bug.cgi?id=3392435 https://bugzilla.nasm.us/show_bug.cgi?id=3392433 ======================== Updated packages in core/updates_testing: ======================== nasm-2.13.03-1.mga6 nasm-doc-2.13.03-1.mga6 nasm-rdoff-2.13.03-1.mga6 nasm-debugsource-2.13.03-1.mga6 nasm-debuginfo-2.13.03-1.mga6 nasm-rdoff-debuginfo-2.13.03-1.mga6 from nasm-2.13.03-1.mga6.src.rpm
Assignee: tmb => qa-bugs
Summary: Update request: nasm-2.13.02 (fixes CVE-2017-1781[0-9] and CVE-2017-17820) => Update request: nasm-2.13.03 (fixes CVE-2017-1781[0-9] and CVE-2017-17820)
Whiteboard: MGA6TOO => (none)Version: Cauldron => 6
Have made a start on this and run one POC test before the update and reproduced the published output, also with gdb. POC testing. CVE-2017-17810 https://bugzilla.nasm.us/show_bug.cgi?id=3392431 For functionality testing: Sample programs at https://www.csee.umbc.edu/portal/help/nasm/sample_64.shtml See also https://en.wikibooks.org/wiki/X86_Assembly/NASM_Syntax
CC: (none) => tarazed25
Mageia 6 :: x86_64 --------------------------------------------------------------------------- Before updates: Could not find nasm-debugsource or nasm-rdoff-debuginfo even after enabling various debug repositories and running MageiaUpdate. Avoided gdb tests after the first one because of lack of knowledge of how the testing framework is implemented and because I suspect that they would not tell us much. The tests were all of the form: $ nasm -f bin POC* -o tmp and produced a list of errors sometimes ending in segfault. The listings were very similar to those published upstream but did not always terminate in the same way. There were aborts and more segfaults in the upstream tests. CVE-2017-17810 https://bugzilla.nasm.us/show_bug.cgi?id=3392431 $ nasm -f bin POC11 -o tmp GNU debugger test: $ gdb nasm .............. Reading symbols from nasm...Reading symbols from /usr/lib/debug/usr/bin/nasm.debug...done. (gdb) set args -f bin POC11 -o tmp (gdb) r Starting program: ........ ............... Program received signal SIGSEGV, Segmentation fault. expand_smacro (tline=0x7ffff7fd8e30, tline@entry=0x7ffff7fd9890) at preproc.c:4340 4340 pt = *ptail = new_Token(tline, ttt->type, (gdb) quit --------------------------------------------------------------------------- After updates: CVE-2017-17810 https://bugzilla.nasm.us/show_bug.cgi?id=3392431 $ nasm -f bin POC11 -o tmp No segmentation fault. CVE-2017-17811 https://bugzilla.nasm.us/show_bug.cgi?id=3392432 $ nasm -f bin POC12 -o tmp No apparent change - no abort CVE-2017-17812 https://bugzilla.nasm.us/show_bug.cgi?id=3392424 $ nasm -f bin POC4 -o tmp Finished tidily - no segfault. CVE-2017-17813 https://bugzilla.nasm.us/show_bug.cgi?id=3392429 $ nasm -f bin POC9 -o tmp Looked the same as before - panic message - no segfault. CVE-2017-17814 https://bugzilla.nasm.us/show_bug.cgi?id=3392430 $ nasm -f bin POC10 -o tmp No change and no segfault. CVE-2017-17815 https://bugzilla.nasm.us/show_bug.cgi?id=3392436 $ nasm -f bin POC15 -o tmp No change and no segfault. CVE-2017-17816 https://bugzilla.nasm.us/show_bug.cgi?id=3392426 $ nasm -f bin POC6 -o tmp Handled quietly after similar diagnostic messages. CVE-2017-17817 https://bugzilla.nasm.us/show_bug.cgi?id=3392427 $ nasm -f bin POC7 -o tmp No change - no abort. CVE-2017-17818 https://bugzilla.nasm.us/show_bug.cgi?id=3392428 $ nasm -f bin POC8 -o tmp No segfault. CVE-2017-17819 https://bugzilla.nasm.us/show_bug.cgi?id=3392435 $ nasm -f bin POC14 -o tmp No segfault. CVE-2017-17820 https://bugzilla.nasm.us/show_bug.cgi?id=3392433 $ nasm -f bin POC13 -o tmp No segfault Summarizing, the diagnostics and behaviour before the updates differed somewhat from the upstream tests; fewer segfaults and no explicit aborts at our end. After the updates all tests finished tidily and the tmp file was not created during any of the afterwards tests. Difficult to make a pronouncement on this but my impression is that nasm is safe to use. Functionality tests later.
I see that the output from POC11 tests went missing. After the update the gdb test shows that the segfault has been squashed. (gdb) set args -f bin POC11 -o tmp (gdb) r Starting program: /usr/bin/nasm -f bin POC11 -o tmp ................... POC11:97: error: label or instruction expected at start of line POC11:98: error: `%%top': not in a macro call POC11:98: error: macro call expects terminating `)' POC11:98: error: macro call expects terminating `)' POC11:98: fatal: macro `%$strucname' expects 5 args [Inferior 1 (process 32534) exited with code 01]
$ rpm -qa | grep nasm nasm-2.13.03-1.mga6 nasm-rdoff-2.13.03-1.mga6 nasm-doc-2.13.03-1.mga6 nasm-debuginfo-2.13.03-1.mga6 Downloaded all the sample files and the Makefile from https://www.csee.umbc.edu/portal/help/nasm/sample_64.shtml and tried them out. $ make all That worked fine, compiling and running all the test files. Corrected a couple of spelling mistakes and reran the tests. $ make recompile rm -f *.out rm -f *.outc make all make[1]: Entering directory '/data/pad/qa/nasm' nasm -f elf64 -l hello_64.lst hello_64.asm gcc -m64 -o hello_64 hello_64.o ./hello_64 > hello_64.out cat hello_64.out Hello world gcc -m64 hello.c ./a.out > hello.outc rm -f a.out nasm -f elf64 -l printf1_64.lst printf1_64.asm gcc -m64 -o printf1_64 printf1_64.o ./printf1_64 > printf1_64.out cat printf1_64.out a=5, rax=7 gcc -m64 printf1_64.c ./a.out > printf1_64.outc rm -f a.out nasm -f elf64 -l printf2_64.lst printf2_64.asm gcc -m64 -o printf2_64 printf2_64.o ./printf2_64 > printf2_64.out cat printf2_64.out printf2: flt2=-1.234568e+302 char1=a, str1=mystring, len=9 char1=a, str1=mystring, len=9, inta1=12345678, inta2=12345678900 hex1=123456789ABCD, flt1=5.327000e-30, flt2=-1.234568e+302 gcc -m64 printf2_64.c ./a.out > printf2_64.outc rm -f a.out nasm -f elf64 -l intarith_64.lst intarith_64.asm gcc -m64 -o intarith_64 intarith_64.o ./intarith_64 > intarith_64.out cat intarith_64.out c=5 , a=3, b=4, c=5 c=a+b, a=3, b=4, c=7 c=a-b, a=3, b=4, c=-1 c=a*b, a=3, b=4, c=12 c=c/a, a=3, b=4, c=4 gcc -m64 intarith_64.c ./a.out > intarith_64.outc rm -f a.out nasm -f elf64 -l fltarith_64.lst fltarith_64.asm gcc -m64 -o fltarith_64 fltarith_64.o ./fltarith_64 > fltarith_64.out cat fltarith_64.out c=5.0, a=3.000000e+00, b=4.000000e+00, c=5.000000e+00 c=a+b, a=3.000000e+00, b=4.000000e+00, c=7.000000e+00 c=a-b, a=3.000000e+00, b=4.000000e+00, c=-1.000000e+00 c=a*b, a=3.000000e+00, b=4.000000e+00, c=1.200000e+01 c=c/a, a=3.000000e+00, b=4.000000e+00, c=4.000000e+00 a=i , a=8.000000e+00, b=1.600000e+01, c=1.600000e+01 a<=b , a=8.000000e+00, b=1.600000e+01, c=1.600000e+01 b==c , a=8.000000e+00, b=1.600000e+01, c=1.600000e+01 gcc -m64 fltarith_64.c ./a.out > fltarith_64.outc rm -f a.out nasm -f elf64 -l fib_64l.lst fib_64l.asm gcc -m64 -o fib_64l fib_64l.o ./fib_64l > fib_64l.out cat fib_64l.out fibonacci numbers 1 2 3 5 < snipped > 7540113804746346429 -6246583658587674878 1293530146158671551 -4953053512429003327 -3659523366270331776 gcc -m64 fib.c ./a.out > fib.outc rm -f a.out nasm -f elf64 -l fib_64m.lst fib_64m.asm gcc -m64 -o fib_64m fib_64m.o ./fib_64m > fib_64m.out cat fib_64m.out fibonacci numbers 1 < snipped > 7540113804746346429 -6246583658587674878 1293530146158671551 -4953053512429003327 -3659523366270331776 No errors or problems of any kind reported. This is good for x86_64.
Whiteboard: (none) => MGA6-64-OK
A minor test for 32-bit code on x86_64: ; hello_32.asm bits 32 extern printf global main section .data message db "Hello world!!", 10, 0 section .text main: pushad push dword message call printf add esp, 4 popad ret ------------------------------------------------------------ Tried building 32-bit code on x86_64 and that worked fine. $ nasm -f elf32 hello_32.asm $ gcc -m32 hello_32.o -o hello32 $ ls hello32* hello_32.asm hello_32.o $ ./hello32 Hello world!!
Re fibonacci sequence in comment 11; I would guess that those negative numbers might have something to do with the sign bit being included in the integer case (unsigned long?).
Mageia 6 :: i586 in virtualbox Downloaded samples from https://www.csee.umbc.edu/portal/help/nasm/sample.shtml Repaired a few omissions and edited the makefile and ran it. That worked fine. Updated nasm and nasm-doc. $ make clean $ make all nasm -f elf -l intarith.lst intarith.asm gcc -o intarith intarith.o ./intarith c=5 , a=3, b=4, c=5 c=a+b, a=3, b=4, c=7 c=a-b, a=3, b=4, c=-1 c=a*b, a=3, b=4, c=12 c=c/a, a=3, b=4, c=4 gcc intarith.c ./a.out c=5 , a=3, b=4, c=5 c=a+b, a=3, b=4, c=7 c=a-b, a=3, b=4, c=-1 c=a*b, a=3, b=4, c=12 c=c/a, a=3, b=4, c=4 rm -f a.out nasm -f elf -l fltarith.lst fltarith.asm gcc -o fltarith fltarith.o ./fltarith c=5.0, a=3.333333e+00, b=4.444444e+00, c=5.000000e+00 c=a+b, a=3.333333e+00, b=4.444444e+00, c=7.777778e+00 c=a-b, a=3.333333e+00, b=4.444444e+00, c=-1.111111e+00 c=a*b, a=3.333333e+00, b=4.444444e+00, c=1.481481e+01 c=c/a, a=3.333333e+00, b=4.444444e+00, c=4.444444e+00 gcc fltarith.c ./a.out c=5.0, a=3.000000e+00, b=4.000000e+00, c=5.000000e+00 c=a+b, a=3.000000e+00, b=4.000000e+00, c=7.000000e+00 c=a-b, a=3.000000e+00, b=4.000000e+00, c=-1.000000e+00 c=a*b, a=3.000000e+00, b=4.000000e+00, c=1.200000e+01 c=c/a, a=3.000000e+00, b=4.000000e+00, c=4.000000e+00 rm -f a.out That looks OK for 32 bits.
Whiteboard: MGA6-64-OK => MGA6-64-OK MGA6-32-OK
Apologies; noticed that the initial output was missing. That was because of previous manual runs so make thought the targets were up-to-date. $ make clean Just showing the start of the listing: $ make all nasm -f elf -l hello.lst hello.asm gcc -o hello hello.o ./hello Hello World nasm -f elf -l printf1.lst printf1.asm gcc -o printf1 printf1.o ./printf1 a=5, eax=7 gcc printf1.c ./a.out a=5, eax=7 rm -f a.out nasm -f elf -l printf2.lst printf2.asm gcc -o printf2 printf2.o ./printf2 Hello world: a string of length 7 1234567 6789ABCD 5.327000e-30 -1.234568E+302 gcc printf2.c ./a.out Hello world: a string 1234567 6789ABCD 5.327000e-30 -1.234000E+302 rm -f a.out nasm -f elf -l intarith.lst intarith.asm
Created attachment 9991 [details] Makefile and sample 32-bit programs
Needs the advisory to be pushed. Validating anyway.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
CC: (none) => tmbKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0129.html
Status: NEW => RESOLVEDResolution: (none) => FIXED