oss-security - Re: CVE-2025-40909: Perl threads have a working directory race condition where file operations may target unintended paths

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87jz5uauhb.fsf@oldenburg.str.redhat.com>
Date: Mon, 02 Jun 2025 20:06:40 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Leon Timmermans <fawaka@...il.com>
Cc: Stig Palmquist <stig@...g.io>,  perl5-porters@...l.org,
  oss-security@...ts.openwall.com
Subject: Re: CVE-2025-40909: Perl threads have a working directory race
 condition where file operations may target unintended paths

* Leon Timmermans:

> On Mon, Jun 2, 2025 at 10:22 AM Florian Weimer via perl5-porters
> <perl5-porters@...l.org> wrote:
>>
>> * Stig Palmquist:
>>
>> > References
>> > ----------
>> > https://github.com/Perl/perl5/commit/918bfff86ca8d6d4e4ec5b30994451e0bd74aba9.patch
>>
>> Is this fix really correct?
>>
>> +    ret = fdopendir(dup(my_dirfd(dp)));
>>
>> This does not create a separate open file description, only a second
>> descriptor that shares the read position of the directory stream with
>> the original directory stream.  I think you have to use something like
>> this:
>>
>>      ret = fdopendir(openat(my_dirfd(dp), ".", O_DIRECTORY | O_CLOEXEC));
>
> Our thread cloning in general is a terribly awkward business, where
> "what is the correct behavior" isn't always well defined or possible;
> I can see the arguments for both to be honest.
>
> For file descriptors we don't create new file descriptions either (we
> don't even create new file descriptors, we refcount them), so why
> should we do so for directory handles? I'm not sure that expectation
> makes sense in that context.

That's a fair point.  It's more like fork in this regard, which has
similar failure cases for DIR * objects (shared file description, but
unshared buffers and a separate descriptor).

> And if we did go the openat way, I don't think that seekdir on the new
> handle with the telldir of the old one is necessarily valid if the
> directory has been changed (I mean even a rewinddir can invalidate
> telldir's return value). I don't think we can do a fully correct copy
> here.

Ugh, I had not considered that.  Yes, glibc will have to switch to an
implementation where telldir offsets are specific to a DIR * for certain
file systems on 32-bit architectures (because telldir returns long, not
off_t).

Hopefully sharing the description isn't much of a problem in practice.

Thanks,
Florian

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.