Re: CVE-2025-22247 - Insecure file handling vulnerability in open-vm-tools

[VMware PSIRT <vmware.psirt () broadcom com>]

Hi Alexander,

We somehow missed your previous e-mail. Thank you for reviving this thread.

Please see our responses below:

> Skimming the code changes, I see that the second part - "disallow
unexpected symlinks in file paths" - is implemented by calling
realpath() (or a Windows function on that platform) and seeing whether
that changed the pathname or (almost) not.  However, this will not
disallow a symlink that appears after the realpath() call but before
subsequent use of the pathname.

Thanks you for raising this. You are right about realpath() and
symlink usage in general. However, as you can see we are performing
realpath() check after we completed the open() but before we read
anything from the file. So, there is no use of pathname after realpath()
call here.


> Is a race condition like this relevant, or is it irrelevant given the
way these tools are normally used?  In other words, is the filesystem
static when this code runs, or is it a live VM where "a malicious actor
with non-administrative privileges" may operate concurrently with this
code running?

As noted, the particular race condition you describe is not a concern.
However, you're correct that the file system may not be static when this
code runs because this code runs in a live VM, so, yes, there may be a
potential for other types of races.  What this fix does is (1) check for
symlinks where previously there was no such check, which helps to avoid
following symlinks when the file system is not changing rapidly and (2)
reduce the window of the vulnerability when the file system is changing rapidly.

We would request you to please let us know at vmware.psirt () broadcom com if
you have further concerns regarding the completeness of the patch. We would
be happy to investigate and provide a resolution.

Thank you again.

Kind Regards,
Praveen Singh | Engineering Program Manager
Email: vmware.psirt () broadcom com

On Wed, Sep 24, 2025 at 8:09 AM Solar Designer <solar () openwall com> wrote:
> Hi,
>
> I'm sorry I just let this stay without a follow-up at the time.  I am
> CC'ing John Wolfe now, who authored the patch commit.
>
> I do think the fix was incomplete.  As someone wrote to me off-list at
> the time (didn't want to post publicly, so I post without attribution):
>
> > I let the oher person respond publicly, but the open-vm-tools runs in the VM as
> > a service and communicates with VMware. So it is both risk to the VM itself and
> > to the VMware ESXi (or vCenter).
>
> To me, this means that the risk of race conditions applies.
>
> Alexander
>
> On Tue, May 13, 2025 at 03:59:57AM +0200, Solar Designer wrote:
> > Hi,
> >
> > Thank you very much VMware PSIRT for fixing and disclosing this issue.
> >
> > I'm sorry I'm not familiar with open-vm-tools, but I thought we could
> > clarify the below for everyone in here:
> >
> > On Mon, May 12, 2025 at 06:57:46PM +0530, VMware PSIRT wrote:
> > > A malicious actor with non-administrative privileges on a guest VM may
> > > tamper the local files to trigger insecure file operations within that VM.
> >
> > > https://github.com/vmware/open-vm-tools/tree/CVE-2025-22247.patch
> >
> > The commit message says:
> >
> > > Prevent usage of illegal characters in user names and file paths.
> > > Also, disallow unexpected symlinks in file paths.
> >
> > Skimming the code changes, I see that the second part - "disallow
> > unexpected symlinks in file paths" - is implemented by calling
> > realpath() (or a Windows function on that platform) and seeing whether
> > that changed the pathname or (almost) not.  However, this will not
> > disallow a symlink that appears after the realpath() call but before
> > subsequent use of the pathname.
> >
> > Is a race condition like this relevant, or is it irrelevant given the
> > way these tools are normally used?  In other words, is the filesystem
> > static when this code runs, or is it a live VM where "a malicious actor
> > with non-administrative privileges" may operate concurrently with this
> > code running?
> >
> > Can you please clarify?
> >
> > Thanks again,
> >
> > Alexander