From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21108 invoked from network); 4 Sep 2020 19:53:07 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 4 Sep 2020 19:53:07 -0000 Received: (qmail 3678 invoked by uid 550); 4 Sep 2020 19:53:05 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3645 invoked from network); 4 Sep 2020 19:53:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1599249172; bh=IOXkD9AUkIwOrE9vUyeWCa4jZokqavj9hrHpjdKrKCM=; h=X-UI-Sender-Class:Date:From:To:Subject; b=hHLgHRQWCTq76XBQuCmngtKzKxBDgfRteiEtrAFh/tXh235XxaT9FK0BeZwa7SHO4 X4m6WWt08/taJ8r4csl8txayfIdav74YgF3sTdMKTx3wym+auDj2cacRMuFFwYiI+p NJDcg9tMaLBimQqpV6LGCS0Q5EihkGD8zuduRDl0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Fri, 4 Sep 2020 21:52:51 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20200904195251.GA2139@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:feE1894I/A1/ZML+dcdSFh74HVDaUlZaRWxCPu3voBTsOxsBrfy 1XWYH5n6wK0+o8HgfrC/wgvgxHpZmeQsJvwc+wim3bxWIF9Yd2o6a9HUk+HwXrXbSQ9RDlx mWg62RVt30J/tmxkUQuwNEC5YokYc1cHPsC3+6h3Lkb+BqvRA3LyT64Zf9KjMOUE6ocmFeF TzKkOjzjmk0PyapDKL7jg== X-UI-Out-Filterresults: notjunk:1;V03:K0:PPhqzR1I6gc=:pt7M5VRdCBs6fiIg5go13H K4C8sb66R/26+RHt7l3ZcF8eHcTSa2/BO7a1fMQDoPKawPG4WzCLtUQdlDdpmR/dF5clthNj2 0g/HzN7g8S9nUqIVBulZNMNMkLzKMnpvl1kPonJNtV0HgDIbrF6aUGrW2NQyfLeBfkmDZubnl 18fgPvslAbA93nO3E00iif4e9DFYWjsbiZ4q8VDze0B1me/om7rMKOJWWXH1v476TXODLXkLE m9VqW1mLuRr6oMQJp4WYazlJb7xP7EIGdOyejb9Bir9hXS/aGapPGt99DfEodVdY5xmfewNNQ PUFoCULTJeQbeSpMK7/GLn38STKfGQ/lHv0FxDU3t+jQZb/Z0MjSFsHoOr9lWX6FeBmfD7gUo j6HlrACBT+36dHLCecCbXrenW+x/3othmIWMXcmSpuswzn8tzKBTsHgQQe5q1KGp2bL6tgINS qYpWyim4qecxIPTivooznRInA7DoSM2Req4WUR7Ra4jdKjW1M1zpy1nirIGOL/oQXaUwJzyLY toZRcsIPHuehZ6uBJf6BXj3TozUCKmjOKZElhc2aSgPzVSLus7/W1B2p+re3rhoHp66z/DeFJ DA9eft0x/u/MtagEfledbaKCtgyqSq60GkhFmz8102eTVlX5jScMFzNH3QBqVJN5Fze532QvD 6Y9fwmUfscxWEWInyCZemSbjlvaEx9tZK5xbsf7DmCI2iuirvixI/t3qSEu3lDWy0CINx1fWc g4xj9VmzEW0adPfqCGo2lclNJZx1M/l2ytOT5F4ccSB4vZ6yM7rdij2l13U44xiQr3qbYBhLf ykwGlyz6PJMOOdO1Fn8BseQbHjjDVgq5z/QsK48bv7y/5ZzxiwfyJfKQWD1wkjVfzKPu58HSb eHqX8m6KmIrJukfm4r4OcTqdNJZwQBapU46tlW1esT0MIs0FGfZFDT0LqkqhvZSIth742pVdm hkbtErGEKb5+LX9+DhfETpfGTqzjexD6VHcx6N1CyZqlOIHB8bNOGoSsp4edNd8QuIVDDw3Gh MSbBfZB8dg28xYXmzZlT3v8/soJa+w0iL4641JHUsYr2ta/UmIlfDKuZOapMCRO3K/V/JNsRC ui6/7P81LGQmW2NeMokjlsRakRdpFgj+oQ+y19FKa5WpNxNjeK3z9uTHjeRYcDFd6nXxgbds+ wn+8YZ8PK+ftMlbjpEPY5t14R7ova5lRKBXDj48NoP8+ZvcZMDcIoAfFlGt14aIOff9qY4HJ0 V/86uyMMkrcFyhucx Subject: [musl] Bug in mmap_fixed() Hi all, now, the subject says "bug", but I don't think the conditions to trigger this are even possible. But still, the code calls attention to it, so here goes. In ldso/dynlink.c there is a small function called mmap_fixed(). This function contains this snippet: | ssize_t r; | if (lseek(fd, off, SEEK_SET) < 0) return MAP_FAILED; | for (q=p; n; q+=r, off+=r, n-=r) { | r = read(fd, q, n); | if (r < 0 && errno != EINTR) return MAP_FAILED; | if (!r) { | memset(q, 0, n); | break; | } | } So when I read this, I immediately thought: What happens when the read() call does fail due to EINTR? The code specifically excludes that error, after all. The answer is that after EINTR, r is going to be -1, which will not be corrected, so the iteration statements will actually back off the target pointer and increase the remaining length. But since the file position isn't also backed off, the results of that read will all be shifted by one byte. If that happens the first time through the loop, the code will also start overwriting one byte which it is not allowed to touch (one byte in front of the buffer). I don't know, can this crash on NOMMU systems? I am aware there were systems in the past lacking an MMU, but having a memory protection unit. I just don't know if Linux runs on any of them. Because here's the crux of the issue: This code is unreachable on anything but Super-H at the moment, since that is the only architecture defining DL_NOMMU_SUPPORT. And it hinges on read() returning EINTR, which, according to signal(7) is impossible: read() can only fail with EINTR on devices where reading can block indefinitely, and those aren't seekable. If someone did manage to push a file on the dynlinker where this can happen, then the lseek() would fail already, and the rest of the code would never run. If I am right that the EINTR is impossible, it might be best to just remove the exception for it. Ciao, Markus