System encryption fails with "The parameter is incorrect" (File::Write) on NVMe disks with AlignmentMask = 0xF (unaligned raw I/O buffer)

Open
  • Is something wrong?
#1,987 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c
Domain
operating-systems, security

Research direction

Start with src/Common/BootEncryption.cpp and trace BootEncryption::Install() through InstallVolumeHeader() into the File::Write and File::Read fallback described in the issue. Check how the device I/O buffers are aligned, then reproduce the system encryption pretest on a device reporting AlignmentMask = 0xF. Done means the pretest writes the header and proceeds to reboot without error or rolling back EFI files.

Written by the indexing model from the issue text.

Description

bug

Expected behavior

Clicking Yes on the prompt to restart for the System Encryption Pretest installs the boot loader and volume header, then restarts.

Observed behavior

Immediately after clicking Yes, before any reboot:

The parameter is incorrect.
Source: VeraCrypt::File::Write:1024

VeraCrypt then rolls back the EFI loader files. The same error also occurred with 1.26.30 (at line 1043, same statement) before that release was pulled.

Root cause

The disk reports AlignmentMask = 0xF (IOCTL_STORAGE_QUERY_PROPERTY, StorageAdapterProperty), so Windows requires raw disk I/O buffers to be 16-byte aligned and rejects others with ERROR_INVALID_PARAMETER (87). Most systems report 0x3, which hides the problem.

Code path (1.26.29, src/Common/BootEncryption.cpp):

  • BootEncryption::Install() calls InstallVolumeHeader(), which writes the 512-byte header at TC_BOOT_VOLUME_HEADER_SECTOR_OFFSET.

  • That WriteFile fails with error 87. Because size % 4096 != 0, the 4K read-modify-write fallback in File::Write runs.

  • The fallback reads into File::ReadBuffer, which is not 16-byte aligned, so it fails the same way and throws at line 1024:

    throw_sys_if (!ReadFile (Handle, ReadBuffer, 4096, &bytesRead, NULL) || (bytesRead != 4096));

On x64, ReadBuffer sits at offset 76 in the File class: vptr (8) + three bools (padded to 16) + FilePointerPosition (8) + Handle (8) + IsDevice
(padded to 40) + wstring Path (32) + LastError (4) = 76. That is 4-byte aligned but never 16-byte aligned. The same fallback code is still present
in master.

Suggested fix

  • Minimal: align the member, e.g. alignas(4096) BYTE ReadBuffer[4096];, so the existing fallback can succeed.
  • Complete: copy through an aligned bounce buffer (VirtualAlloc or _aligned_malloc, aligned to at least the sector size) in File::Read and
    File::Write for all device I/O, since writes whose size is a multiple of 4096 from an unaligned caller buffer skip the fallback.
  • Optional: log the device AlignmentMask to make reports easier to diagnose.

Since most test hardware reports 0x3, a debug assertion that device I/O buffers are 16-byte aligned would catch these cases on any machine.

Ruled out

  • Not Intel RST/VMD: controller is Microsoft Standard NVM Express Controller (stornvme).
  • BitLocker fully decrypted, no third-party security software, EFI partition has 484 MB free.
  • Not the Windows native NVMe stack (#1640): on the second affected Dell (KIOXIA, below), the disk is in the DiskDrive class, not NvmeDisk.

Related

  • Forum thread with the original analysis and two more affected machines (Lenovo X1 Carbon Gen 14 / Samsung NVMe, ASUS Vivobook Go 15 / Micron UFS): https://sourceforge.net/p/veracrypt/discussion/technical/thread/a136c4a1b8/
  • A second Dell Pro 5 14 (P514260) with a KIOXIA EG7 512GB NVMe SSD (firmware 12400102, PCIe 4.0 x4) also reports AlignmentMask = 0xF, so
    this is not specific to one SSD vendor on this model. VeraCrypt has not been run on it, but BestCrypt Volume Encryption failed on it reading
    sector 0. A vendor test build with alignment changes got past that point, which supports buffer alignment as the cause.

Steps to reproduce

  1. System > Encrypt System Partition/Drive (single boot, encrypt Windows partition)
  2. Complete the wizard up to the pretest restart prompt
  3. Click Yes
  4. The error appears before any reboot

Screenshots

None. The error text is quoted above.

Your Environment

Please tell us more about your environment

VeraCrypt version: 1.26.29

Operating system and version: Windows 11

System type: 64-bit

Hardware:

  • Dell Pro 5 14 (P514260), UEFI, GPT
  • SSD: SanDisk PC SN5100S 512GB (Dell OEM), firmware 35012203
  • Sector size: logical 512, physical 4096
  • Controller: Standard NVM Express Controller (stornvme)
  • AlignmentMask: 0xF

I can test a build on the second Dell (KIOXIA) if that helps.

Dominant language
C
Stars
11.7k
Forks
1.4k
Avg merge
1d 1h
Merged PRs (30d)
28

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from veracrypt/VeraCrypt

All issues in veracrypt/VeraCrypt

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.