CVE-2026-68098

You're looking at CVE-2026-68098, a kernel-heap read-past-valid-bounds in ksmbd's DACL reconstruction logic. The vulnerability lives in set_ntacl_dacl(), where a single variable (nt_num_aces) was carrying two semantically distinct meanings simultaneously: tracking whether the input DACL contained NT ACEs (for fallback decisions) and serving as the iteration bound for the deduplication walk over the output array. These are fundamentally different operations — one characterizes input, the other bounds output construction. The failure triggers when size-accounting overflow occurs during the ACE copy. The code path that should prevent overflow is exactly where the semantic conflation breaks down: the variable that correctly tracked input composition now incorrectly bounds the dedup walk, causing the scan to read past the valid copied ACEs into whatever kernel heap memory follows the output buffer. This is a read vulnerability, not a write — the dedup walk is probing adjacent heap memory it shouldn't access. What makes this exploitable is ksmbd's position: kernel-space, network-adjacent, and handling SMB traffic from potentially thousands of unauthenticated clients. The heap layout relative to the rebuilt DACL determines whether this is information disclosure or something worse. An attacker controlling heap allocation patterns through SMB requests could position usable data adjacent to the output buffer, turning the over-read into a controlled information leak or a stepping stone toward privilege escalation. The patch separates the two concerns explicitly: one variable tracks whether NT ACEs existed in input, a separate count tracks how many were successfully copied. This is the correct fix, but the pattern here — conflating 'input existed' semantics with 'output bound' semantics — is a known failure mode in translation-layer code where Windows ACL semantics map to POSIX permissions. Expect static analysis tooling targeting this pattern to have false negatives; the semantic divergence only occurs under overflow conditions that are difficult to trigger in normal testing. For detection: monitor for anomalous SMB sessions generating ACL operations that could produce the overflow condition. The read-past-buffer itself leaves minimal forensic trace in standard logs — you won't see a crash or corruption, just unexpected memory exposure. Consider whether your heap debugging tools (kmemleak, SLUB debug) are viable in your production kernel configuration, recognizing the performance cost.

Reviewed through automated stages and approved by a human before publication.