This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix readdir_r with long file names
- From: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: mtk dot manpages at gmail dot com, Rich Felker <dalias at aerifal dot cx>, Carlos O'Donell <carlos at redhat dot com>, KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, linux-man <linux-man at vger dot kernel dot org>
- Date: Wed, 2 Mar 2016 09:17:37 +0100
- Subject: Re: [PATCH] Fix readdir_r with long file names
- Authentication-results: sourceware.org; auth=none
- References: <51B0B39F dot 4060202 at redhat dot com> <51B0BD36 dot 3030202 at redhat dot com> <CAHGf_=r9Rz63pho+84ORk0a_oDyJSj-MCnZ56uPrT3L6sVEfeQ at mail dot gmail dot com> <20130607013024 dot GO29800 at brightrain dot aerifal dot cx> <51B19203 dot 3070307 at redhat dot com> <20130607144143 dot GQ29800 at brightrain dot aerifal dot cx> <51B57E35 dot 4080403 at redhat dot com> <51B65EA7 dot 2020402 at redhat dot com> <20130611011324 dot GT29800 at brightrain dot aerifal dot cx> <51B8702D dot 2060505 at redhat dot com> <20130813040038 dot GE21795 at spoyarek dot pnq dot redhat dot com> <520C88A6 dot 9070501 at redhat dot com> <56D54DAD dot 1040306 at gmail dot com> <56D5CA79 dot 9030204 at redhat dot com> <56D5F832 dot 3070209 at gmail dot com> <56D5FB3D dot 5000306 at redhat dot com> <56D60335 dot 7010906 at gmail dot com> <56D615D7 dot 5020304 at redhat dot com>
On 03/01/2016 11:21 PM, Florian Weimer wrote:
> On 03/01/2016 10:01 PM, Michael Kerrisk (man-pages) wrote:
>> On 03/01/2016 09:27 PM, Florian Weimer wrote:
>>> On 03/01/2016 09:14 PM, Michael Kerrisk (man-pages) wrote:
>>>
>>>> What happens with readdir() when it gets a filename that is larger
>>>> than 255 characters?
>>>
>>> Good question. Ugh.
>>>
>>> readdir will return a pointer to a struct dirent whose d_name member
>>> will not be null-terminated, but the memory following the struct dirent
>>> object will contain the rest of the name, and will eventually be
>>> null-terminated.
>>
>> So, in other words, if the caller users a declaration of the form
>>
>> struct dirent d;
>>
>> (rather than say allocating a large buffer dynamically), then we have
>> a buffer overrun?
>
> readdir gives you only a struct dirent * to an internal buffer.
D'oh! Yes, of course. I wasn't thinking clearly as I wrote that last night.
> If you do
>
> struct dirent *e = readdir (dir);
> memcpy (&d, e, sizeof (d));
>
> you can end up with a truncated name.
Got it.
> According to Paul's comment, this
> kind of truncation is very visible on Solaris.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/