DiskUtils.TryGetReparseDataBuffer reads a struct from unzeroed pooled memory and ignores the number of bytes returned
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start with TruePath/DiskUtils.cs at TryGetReparseDataBuffer and inspect how DeviceIoControl reports the number of bytes returned. Check how IsJunction consumes the result and how SymbolicLinkReparseBuffer represents tag-specific fields. Done when short responses cannot produce a successful read of stale data and fields are interpreted according to the reparse tag.
由索引模型根据 Issue 内容生成。
描述
DiskUtils.TryGetReparseDataBuffer reads a SymbolicLinkReparseBuffer out of a buffer rented from ArrayPool<byte>.Shared:
byte[] buffer = ArrayPool<byte>.Shared.Rent(MAXIMUM_REPARSE_DATA_BUFFER_SIZE);
// ... DeviceIoControl(..., out _, ...) // bytes returned are discarded
Span<byte> bufferSpan = new(buffer);
success = MemoryMarshal.TryRead(bufferSpan, out SymbolicLinkReparseBuffer reparseDataBuffer);
Two things are wrong here:
- Pooled arrays are not zeroed, and the number of bytes written by
DeviceIoControlis ignored. The span covers the whole (larger-than-needed) array, soTryReadalways succeeds, even when the driver returned fewer bytes thansizeof(SymbolicLinkReparseBuffer)(20 bytes). Reparse points with little or no payload leave the remaining fields filled with leftovers of whatever previously used the pooled array. SymbolicLinkReparseBufferis a symlink-specific layout. ItsFlagsfield only exists for symlinks. For junctions (mount points), and for other tags, the same four bytes arePathBuffercontents or arbitrary data.
No wrong result is observable today, because the only consumer, DiskUtils.IsJunction, reads just ReparseTag, which is always in the first four bytes of a successful response. But the method is a trap for the next person who reads another field. It reads uninitialized (stale) data and returns a struct whose fields can be garbage while the method reports success.
Recommendations
- Capture
lpBytesReturnedand usenew Span<byte>(buffer, 0, (int)bytesReturned), so thatTryReadfails for a response that's too short. - Better: make the method return only what it can actually vouch for. Either return just the
ReparseTag(that's allIsJunctionneeds), or expose a header-only struct (ReparseTag,ReparseDataLength,Reserved) and parse the tag-specific part per tag. - Rename or document the struct accordingly, so it's clear that
Flagsis valid only forIO_REPARSE_TAG_SYMLINK.
- 主要语言
- C#
- 星标
- 107
- 派生
- 22
- 平均合并
- 3 天 2 小时
- 30 天内合并 PR
- 13
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
ForNeVeR/TruePath 的其他 Issue
-
Wrong values of Kernel32.FileShare.Delete and Kernel32.FileAttributes.PosixSemantics可能已有人在做 @ElectLive 于 1 天前认领。 未关闭bug good first issue help wanted
难度 1/5 1 小时以内 新手友好度 83/100
ForNeVeR/TruePath#241 · 1 条评论 ·
维护者通常 1 天内回复
-
AbsolutePath.ReadKind allocates a new 16 KiB buffer per directory on Windows: the pooled buffer is not returned on failure可能已有人在做 @FalconTechDev 于 1 天前认领。 未关闭enhancement good first issue help wanted
难度 2/5 1-3 小时 新手友好度 78/100
ForNeVeR/TruePath#240 · 1 个 reaction ·
维护者通常 1 天内回复
-
enhancement good first issue help wanted
难度 2/5 1-3 小时 新手友好度 68/100
ForNeVeR/TruePath#165 · 2 条评论 ·
维护者通常 1 天内回复
-
Windows tests: symlink access requires dev mode or elevated access可能已有人在做 @hamdiakin 今天认领。 未关闭documentation help wanted
难度 3/5 1-2 天 新手友好度 57/100
ForNeVeR/TruePath#245 · 1 条评论 ·
维护者通常 1 天内回复
-
enhancement help wanted
难度 5/5 一周以上 新手友好度 35/100
维护者通常 1 天内回复
查看 ForNeVeR/TruePath 的全部 Issue
相似的 Issue
-
bug priority: P2
难度 1/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 77/100
维护者通常 1 天内回复
-
[Docs] README/PRIVACY still name AppCenter although v1.5.6.0+ uses the Microsoft Store Services SDK未关闭
难度 2/5 1-3 小时 新手友好度 78/100
-
needs-triage
难度 2/5 1-3 小时 新手友好度 72/100
Azure/azure-sdk-tools#17317 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 66/100
swisstopo/swissgeol-boreholes-suite#3086 ·
维护者通常 1 天内回复