public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "tatannen at wisc dot edu" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/13601] New: Fail to load dynamic libs when entire ELF header cannot be read in one syscall Date: Wed, 18 Jan 2012 04:15:00 -0000 [thread overview] Message-ID: <bug-13601-131@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=13601 Bug #: 13601 Summary: Fail to load dynamic libs when entire ELF header cannot be read in one syscall Product: glibc Version: 2.14 Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: drepper.fsp@gmail.com ReportedBy: tatannen@wisc.edu Classification: Unclassified As stated in the man pages, the read() system call may read/return less bytes than requested, for a variety of well-documented reasons. In elf/dl-load.c, function open_verify() attempts to read the entire elf header (over 800 bytes on x86_84) in one invocation of the read system call, and if all bytes are not read, the shared library will not load with a "file too short" error. This could cause failures, for instance, loading over networked file systems configured with a small (less than 800byte) MTU size. In elf/dl-load.c the problem is here: 1714: size_t maplength; 1715: 1716: /* We successfully openened the file. Now verify it is a file 1717: we can use. */ 1718: __set_errno (0); 1719: fbp->len = __libc_read (fd, fbp->buf, sizeof (fbp->buf)); 1720: 1721: /* This is where the ELF header is loaded. */ 1722: assert (sizeof (fbp->buf) > sizeof (ElfW(Ehdr))); 1723: ehdr = (ElfW(Ehdr) *) fbp->buf; 1724: 1725: /* Now run the tests. */ 1726: if (__builtin_expect (fbp->len < (ssize_t) sizeof (ElfW(Ehdr)), 0)) 1727: { 1728: errval = errno; On line 1719, if the read returns less than sizeof (ElfW(Ehdr)) as tested on line 1726, the library load will fail. The call to libc_read on line 1719 should be repeated while libc_read returns a value greater than zero. If you desire me to write/submit a patch, I'd be happy to help out, just ask. Thank you! -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
next reply other threads:[~2012-01-18 4:15 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-01-18 4:15 tatannen at wisc dot edu [this message] 2012-02-21 2:34 ` [Bug ld.so|libdl/13601] " jsm28 at gcc dot gnu.org 2012-10-20 3:31 ` [Bug dynamic-link/13601] " siddhesh at redhat dot com 2014-06-27 11:11 ` fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-13601-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).