Bug 503723

Summary: fopen mode 'x' ignored in some cases
Product: [Fedora] Fedora Reporter: Sami Farin <hvtaifwkbgefbaei>
Component: glibcAssignee: Andreas Schwab <schwab>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: rawhideCC: drepper, fweimer, jakub, schwab, security-response-team, thoger
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 509853 509855 (view as bug list) Environment:
Last Closed: 2009-08-10 14:15:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 509853, 509855    
Attachments:
Description Flags
fopen.c - test for fopen modes none

Description Sami Farin 2009-06-02 12:00:51 UTC
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

Comment 1 Tomas Hoger 2009-06-02 15:28:21 UTC
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.

Comment 2 Ulrich Drepper 2009-06-09 14:02:34 UTC
I've checked in a patch upstream.

Comment 3 Tomas Hoger 2009-06-09 14:07:08 UTC
Thank you!  Commit diff link for posterity:
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=0d74e0436195a051d69e78bef10d23879788cb7e

Comment 4 Noura El hawary 2009-06-09 21:48:30 UTC
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

Comment 5 Andreas Schwab 2009-08-10 14:15:17 UTC
Fixed in 2.10.1-4.