VeraCrypt 1.26.29 hangs with "--auto-mount=favorites" when mounting multiple favorite volumes on Fedora

[novaxar]

I have two entries in the Favorites list that were added through the VeraCrypt GUI:

1. Partition (password and PIM):
   /dev/nvme0n1pX -> /media/docs
2. File container (password only):
   /media/docs/foo/bar/container -> /media/container

When I run veracrypt --auto-mount=favorites, VeraCrypt 1.26.29 mounts the first favorite volume successfully, but then hangs, consumes 100% of one CPU core, and never prompts for the credentials of the second favorite volume.

Both volumes can be mounted manually without any issues using the GUI. The problem only occurs when using veracrypt --auto-mount=favorites.

The same setup works correctly with VeraCrypt 1.26.24. The issue only appears after upgrading to version 1.26.29.

Expected behavior

Running the following command:

veracrypt --auto-mount=favorites

should automatically mount all volumes stored in Favorites.

Since my two favorite volumes use different passwords (and PIM), VeraCrypt should:

1. Prompt for the password and PIM of the first volume.
2. Mount the first volume.
3. Prompt for the password of the second volume.
4. Mount the second volume.

Observed behavior

When I run:

veracrypt --auto-mount=favorites

1. VeraCrypt prompts for the password and PIM of the first volume.
2. After entering the correct credentials, the first volume is mounted successfully.
3. After that, VeraCrypt starts consuming 100% of one CPU core and approximately 1 GiB of RAM. The resource usage does not stop even after waiting for an extended period of time, and the second favorite volume is never mounted.

The only way to stop the process is to terminate it manually using kill. After killing the process, VeraCrypt displays an error message (see screenshot below).

My suspicion is that VeraCrypt may be repeatedly trying to unlock the second favorite volume using the password/PIM entered for the first volume instead of prompting for a new password. Another possibility is that VeraCrypt is hitting a race condition. But these are just my assumptions.

Steps to reproduce

1. Add two encrypted volumes to the Favorites list using GUI.
2. Run veracrypt --auto-mount=favorites
3. Enter the correct password and PIM for the first favorite volume.
4. The first volume is mounted successfully.
5. VeraCrypt never prompts for the credentials of the second favorite volume.
   Instead, VeraCrypt starts consuming one CPU core at 100% and around 1 GiB of RAM indefinitely, while the second volume is never mounted.
6. Terminate the process using kill.
7. VeraCrypt displays an error message (see screenshot).

Screenshots

Resource consumption after mounting the first volume:

The error message after terminating the VeraCrypt process with kill:

Your Environment

VeraCrypt version: 1.26.29
GitHub release file: veracrypt-1.26.29-Fedora-44-x86_64.rpm

Operating system and version:

1. Fedora Linux 44 (KDE Plasma Desktop Edition): stable release and the latest updates
2. Kernel: 7.1.3-200.fc44.x86_64

System type: x86_64

[idrassi]

Thanks for the detailed report. This looks like a real regression in the 1.26.24 -> 1.26.29 interval. The favorite auto-mount path may be reusing mount options across favorites, so after the first interactive mount, fields such as password, PIM, and selected KDF may still be present when the next favorite is tried. This means the second favorite can first be attempted with the credentials/PIM entered for the first favorite before VeraCrypt displays the next prompt.

With Argon2 now present in KDF autodetection path, a failed autodetection attempt using an inherited large PIM can run inside the elevated core service and consume up to about 1 GiB of RAM while taking a very long time. This matches the screenshot showing /usr/bin/veracrypt --core-service consuming around 1.0G.

The Broken pipe message after killing the process is secondary, caused by terminating the GUI/elevated service IPC while the mount request is still busy.

Could you confirm the PIM value used for the first favorite (is it larger than 31?), the KDF dropdown value used during the first prompt, and whether password caching was enabled? As a workaround, specify the exact KDF used by each favorite instead of Autodetection.

Meanwhile, I will work on a fix.

[novaxar]

Could you confirm the PIM value used for the first favorite (is it larger than 31?)

Yes, I chose PIM in the range of 1000-1500.

the KDF dropdown value used during the first prompt

I used the default "Autodetection" option and did a new test:

After selecting the exact KDF value, everything works as in the previous version:

1. The first favorite is mounted successfully.
2. VeraCrypt tries to mount the second favorite with the same credentials, but without success.
3. and displays a window for entering credentials for the second favorite and displays the PIM value from the first one.

In this scenario, no freezing occurs.

whether password caching was enabled?

No.

---

Unfortunately, it is not possible to change the mount options for favorite volumes in the VeraCrypt GUI on Linux. For example, specify the KDF value for the desired volume.

Therefore, you have to either select the KDF value each time you mount, or specify the default option for KDF in the Settings and add all favorite volumes again.

[idrassi]

Thank you for the confirmation. The large PIM value together with Autodetection explains the behavior: after the first favorite was mounted, VeraCrypt 1.26.29 could reuse the same mount options for the next favorite, including the password, PIM and KDF selection. With Autodetection this could make the failed attempt on the second favorite try Argon2 with that large PIM, which explains the 1 GiB memory usage and very long runtime in the elevated core service.

Your test with an explicit KDF confirms this: the second favorite was still initially tried with the first favorite’s credentials and PIM, but without the expensive Argon2 autodetection path it failed quickly and showed the next password dialog.

I have implemented a fix (9cabe0d) so that each favorite volume gets its own fresh copy of the initial mount options before favorite-specific fields are applied. This prevents password, PIM and KDF values entered for one favorite from carrying over to the next one.

Concerning the GUI management of mount options for favorites, this is indeed missing on Linux and macOS compared to what is available on Windows. This is a separate issue and I will look on how to enhance this part.

[novaxar]

VeraCrypt 1.26.29 could reuse the same mount options for the next favorite, including the password, PIM and KDF selection.

Is this expected behavior? The likelihood that two volumes will have the same credentials is extremely low.

I have implemented a fix (9cabe0d) so that each favorite volume gets its own fresh copy of the initial mount options

Could this fix be released in the future or will it exist as an experimental option for now?

Concerning the GUI management of mount options for favorites, this is indeed missing on Linux and macOS compared to what is available on Windows. This is a separate issue and I will look on how to enhance this part.

Thanks for working on this!

[idrassi]

Is this expected behavior? The likelihood that two volumes will have the same credentials is extremely low.

No, this was not expected behavior. Reusing the password/PIM/KDF entered for one favorite when processing the next favorite was a regression.
The only intended convenience is the normal password cache mechanism when it is explicitly enabled: it shouldn't cause mount options such as PIM or KDF selection to leak between favorites.

Could this fix be released in the future or will it exist as an experimental option for now?

The fix is not experimental. It will be included in the upcoming VeraCrypt 1.26.30 release.

[novaxar]

It will be included in the upcoming VeraCrypt 1.26.30 release.

Thank you for your work! What is the planned release date for VeraCrypt 1.26.30?