From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 888FB388C024; Thu, 30 Jul 2020 18:04:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 888FB388C024 From: "jasonwhite at fb dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/26322] New: Libraries may fail to load if (p)read doesn't return all bytes requested Date: Thu, 30 Jul 2020 18:04:21 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.33 X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: jasonwhite at fb dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 18:04:21 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26322 Bug ID: 26322 Summary: Libraries may fail to load if (p)read doesn't return all bytes requested Product: glibc Version: 2.33 Status: UNCONFIRMED Severity: minor Priority: P2 Component: dynamic-link Assignee: unassigned at sourceware dot org Reporter: jasonwhite at fb dot com Target Milestone: --- In `elf/dl-load.c` there is a call to pread[1]: if ((size_t) __pread64_nocancel (fd, (void *) phdr, maplength, ehdr->e_phoff) !=3D maplength) { read_error: errval =3D errno; errstring =3D N_("cannot read file data"); goto call_lose; } However, there is no guarantee that pread will return all the bytes request= ed. Thus, I believe the read should be wrapped in a loop to ensure it receives = all the bytes requested. I found this issue while simulating a pathological kernel that only returns= one byte at a time for read calls using ptrace. I imagine this could also be reproduced by writing a small FUSE file system that only returns a byte at a time for reads. [1]: https://sourceware.org/git/?p=3Dglibc.git;a=3Dblob;f=3Delf/dl-load.c;h=3Dc1= bc8c26be1229fafc2a03afd9fb27edbcf8c3a8;hb=3D95c1056962a3f2297c94ce47f0eaf0c= 5b6563231#l1667 --=20 You are receiving this mail because: You are on the CC list for the bug.=