Created attachment 346240 [details] fopen.c - test for fopen modes Description of problem: O_EXCL is not used if mode is "wbex", but O_EXCL is used if mode is "wbxe". This bug can cause security vulnerabilities in software relying on this glibc extension. Version-Release number of selected component (if applicable): 2.10.1-2, 2.9.90-3 How reproducible: always Steps to Reproduce: 1. compile attached C source file 2. run with options ababab wbex, and ababab wbxe 3. Actual results: 'x' may be ignored Expected results: 'x' not ignored Additional info: $ strace -eopen ./a.out ababab wbxe 2>&1 | grep ababab ; rm -f ababab open("ababab", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_CLOEXEC, 0666) = 3 $ strace -eopen ./a.out ababab wbex 2>&1 | grep ababab ; rm -f ababab open("ababab", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 3
Problem seems to be in _IO_new_file_fopen() in libio/fileops.c. Unlike other recognized mode characters, 'e' and 'c' are treated as last character of the mode string: http://sourceware.org/git/?p=glibc.git;a=blob;f=libio/fileops.c;h=cf47c915a7#l320 Not sure if that is intentional, rather looks like a bug caused by odd use of continue vs. break due to the way switch is nested inside for loop. Are you aware of any application relying on this already? Quick google code search did not find anything, though it's obviously easy to miss cases where mode is passed via some other variable.
I've checked in a patch upstream.
Thank you! Commit diff link for posterity: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=0d74e0436195a051d69e78bef10d23879788cb7e
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fixed in 2.10.1-4.