From: Danny Milosavljevic <dannym@scratchpost.org>
To: Marius Bakke <marius@gnu.org>
Cc: 43591@debbugs.gnu.org
Subject: [bug#43591] [PATCH core-updates] gnu: glibc-final: Catch all cases of a glibc user not requesting 64-bit offsets and then using readdir.
Date: Fri, 25 Sep 2020 17:33:20 +0200 [thread overview]
Message-ID: <20200925173320.593e9179@scratchpost.org> (raw)
In-Reply-To: <20200925153646.6ef95908@scratchpost.org>
[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]
Hi,
I wrote a FUSE filesystem to test what happens with big d_off (I just
hard-or-ed a bitmask) and ran it on a real ARMHF machine, then made the program
from before([1] from before) look into that directory.
Result (on ARMHF, so real 32 bit machine!):
$ gcc --version
gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
$ gcc a00.c
$ ./a00
1737031971 .
1737032035 ..
1737032035 hello
$ gcc -D_FILE_OFFSET_BITS=64 a00.c
$ ./a.out
320255973458211 .
320255973458275 ..
320255973458275 hello
(Note: Guix gcc-toolchain 10 on ARMHF is still building from source--and
will continue to do so for some hours I guess)
I only had to patch fuse 2.9.4 (lib/fuse_lowlevel.c) to do this:
char *fuse_add_dirent(char *buf, const char *name, const struct stat *stbuf,
off_t off)
{
unsigned namelen = strlen(name);
unsigned entlen = FUSE_NAME_OFFSET + namelen;
unsigned entsize = fuse_dirent_size(namelen);
unsigned padlen = entsize - entlen;
struct fuse_dirent *dirent = (struct fuse_dirent *) buf;
dirent->ino = stbuf->st_ino;
dirent->off = off | 0x1234567890123; // !!!!
dirent->namelen = namelen;
dirent->type = (stbuf->st_mode & 0170000) >> 12;
strncpy(dirent->name, name, namelen);
if (padlen)
memset(buf + entlen, 0, padlen);
return buf + entsize;
}
(I DID NOT have to patch the kernel or even have root)
So it can happen that you get 64 bit d_off even on real 32 bit machines!
That's what I thought--but I still wanted to make sure.
And the same on Guix i686 (a00 is [1] from my previous e-mail):
$ ./a00-i686
readdir: Value too large for defined data type
$ ./a00-i686_flag_32
readdir: Value too large for defined data type
$ ./a00-i686_flag_64
320255973458211
320255973458275
320255973458275
So there you have it, even on i686--without emulating anything--you can get a
64 bit d_off value.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-09-25 15:35 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 14:12 [bug#43591] [PATCH core-updates] gnu: glibc-final: Catch all cases of a glibc user not requesting 64-bit offsets and then using readdir Danny Milosavljevic
2020-09-24 14:16 ` Danny Milosavljevic
2020-09-24 18:17 ` Marius Bakke
2020-09-24 20:27 ` Danny Milosavljevic
2020-09-24 23:11 ` Marius Bakke
2020-09-25 10:20 ` Danny Milosavljevic
2020-09-25 10:42 ` [bug#43591] [PATCH v2 core-updates] gnu: glibc-final: Catch all cases of a glibc user not requesting 64-bit offsets and then using readdir regardless Danny Milosavljevic
2020-09-25 13:36 ` [bug#43591] [PATCH core-updates] gnu: glibc-final: Catch all cases of a glibc user not requesting 64-bit offsets and then using readdir Danny Milosavljevic
2020-09-25 15:33 ` Danny Milosavljevic [this message]
2020-09-26 1:42 ` Danny Milosavljevic
2020-09-26 1:49 ` Danny Milosavljevic
2020-09-29 14:51 ` Danny Milosavljevic
2020-09-27 6:43 ` Efraim Flashner
2020-09-25 20:03 ` Andreas Enge
2020-09-26 10:50 ` Danny Milosavljevic
2020-09-29 20:52 ` Ludovic Courtès
2020-09-29 22:09 ` Danny Milosavljevic
2020-09-30 9:32 ` Ludovic Courtès
2020-09-30 10:28 ` Danny Milosavljevic
2020-10-01 7:14 ` Ludovic Courtès
2020-10-02 7:18 ` Danny Milosavljevic
2020-10-02 8:12 ` Danny Milosavljevic
2020-10-02 9:47 ` Danny Milosavljevic
2020-10-02 9:32 ` Danny Milosavljevic
2020-10-06 15:39 ` Danny Milosavljevic
2020-09-25 10:24 ` Danny Milosavljevic
2020-09-30 8:45 ` [bug#43591] [PATCH core-updates v2 0/5] " Danny Milosavljevic
2020-09-30 8:45 ` [bug#43591] [PATCH core-updates v2 1/5] gnu: glibc-final: Catch all cases of a glibc user not requesting 64-bit offsets and then using readdir regardless Danny Milosavljevic
2020-09-30 16:55 ` Danny Milosavljevic
2020-09-30 8:45 ` [bug#43591] [PATCH core-updates v2 2/5] build-system/gnu: Explicity declare the _FILE_OFFSET_BITS we want Danny Milosavljevic
2020-09-30 8:45 ` [bug#43591] [PATCH core-updates v2 3/5] gnu: glibc: Do not explicitly set _FILE_OFFSET_BITS Danny Milosavljevic
2020-09-30 8:45 ` [bug#43591] [PATCH core-updates v2 4/5] gnu: glibc-mesboot0: " Danny Milosavljevic
2020-09-30 8:45 ` [bug#43591] [PATCH core-updates v2 5/5] gnu: rhash: Explicity declare the _FILE_OFFSET_BITS we want Danny Milosavljevic
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200925173320.593e9179@scratchpost.org \
--to=dannym@scratchpost.org \
--cc=43591@debbugs.gnu.org \
--cc=marius@gnu.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
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).