On i386 systms, /usr/lib/libFLAC.so.4.1.2 is erroneously marked as requiring an executable stack. This is because it uses several assembler source files that do not contain a .note.GNU-stack section indicating that an exectuable stack is unnecessary. As a result, any application which links to libFLAC.so.4 has an executable stack. This is a security risk. This can be fixed by either: a) adding appropriate .note.GNU-stack sections to each assembler file b) linking with the "-z noexecstack" option or c) running "execstack -c" on the final library Attached is a patch which implements option C.
Created attachment 110405 [details] Patch against the RPM .spec to mark libFLAC as noexecstack
Did you double-check that the included assembly actually does not require an executable stack? It probably doesn't, but I'm nervous about applying this patch without at least a glance from an x86 assembler guru.
I didn't, but I seriously doubt that they need an executable stack. Programatically generating code is difficult enough without doing it in assembly. I am not an x86 assembler guru, but my quick overview didn't find anything suspicious.
I had a guru look over it, he agreed. Unfortunately though, "prelink" and hence execstack isn't available in our buildroots. I'm going to try emailing upstream to get them to add the .note.GNU-stack thing; unfortunately the only samples I have of that are for gnu as, not nasm.
Ah, I was hoping that the "don't use execstack" advice (in another bug) was just bad form, not an outright impossibility. I don't think NASM supports the directives necessary to actually add the right kind of .note.GNU-stack section, so you're left with the option of modifying the final libFLAC.so link with "-z noexecstack".
Nicholas, is this still a problem with flac 1.1.4?
Doesn't look like it: [mclasen@localhost ~]$ execstack /usr/lib/libFLAC.so.8 - /usr/lib/libFLAC.so.8
Excellent, thanks Matthias.