NtQueryInformationFile(FilePositionInformation) lacks access/sync check (asymmetric with NtSetInformationFile fix 8e8a82ce)

[CvvT]

Summary

8e8a82ce ("Enforce access and synchronous mode for NtSetInformationFile file position") correctly hardened the SET path of FilePositionInformation, but the sibling QUERY path was not updated symmetrically. This is a low-severity NT-parity gap, not the cross-handle mutation vector that 8e8a82ce closed.

Detail

• SET path (sys_nt_set_information_file, litebox_shim_windows/src/syscalls/file.rs:1189-1204): resolves the handle via typed_handle_entry_with_access_check requiring FILE_READ_DATA | FILE_WRITE_DATA, and rejects non-SYNCHRONOUS_IO handles with INVALID_PARAMETER. Correct.
• QUERY path (sys_nt_query_information_file / FilePositionInformation, file.rs:1112): still uses the type-only self.file_entry(file_handle) lookup — no granted-access check and no synchronous-mode check.

Impact

A metadata-only handle duplicate (lacking FILE_READ_DATA/FILE_WRITE_DATA) can still read the current byte offset via NtQueryInformationFile(FilePositionInformation). This is read-only offset disclosure, not cross-handle mutation, so severity is low. Real NT requires FILE_READ_DATA | FILE_WRITE_DATA for the query as well, so the current behavior is a fidelity divergence.

Suggested fix

Route the query path through the same access-aware lookup (FILE_READ_DATA | FILE_WRITE_DATA) and apply the SYNCHRONOUS_IO check, mirroring the SET path, with regressions for the metadata-only-duplicate and asynchronous-handle cases.

Notes

• Discovered during red-team of 8e8a82ce; does not block that commit's APPROVE.
• Non-blocking / CI-independent parity item.