Log / Transaction Drivers
Log and transaction file system drivers manage structured log files used by the OS for crash recovery, transactional NTFS, and application logging. The Common Log File System (CLFS) is the primary target in this category.
Architecture
- Driver model: WDM kernel-mode driver
- Key subsystem: CLFS (Common Log File System) —
clfs.sys - Data structures: Base log files (.blf), container files, metadata blocks, symbol zones
- Consumers: TxF (Transactional NTFS), Windows Error Reporting, application logging
Attack Surface
- Base log file parsing:
.blffiles contain metadata blocks with offsets, lengths, and symbol tables — all attacker-controllable via crafted log files - Container management: Container queue loading with untrusted index/length fields
- Metadata block writes:
WriteMetadataBlockandFlushImageoperate on partially validated structures - User-mode reachable: Standard users can create and manipulate CLFS log files via
CreateLogFile
Why CLFS Is a Repeat Target
CLFS has been exploited 7+ times (4 in our corpus) because:
- Complex binary metadata format with many offset/length fields to corrupt
- User-mode reachable from standard user context
- Pool allocations based on untrusted file metadata
- Each patch fixes one corruption vector but the metadata surface is large
Common Vulnerability Patterns
| Pattern | Description | AutoPiff Rules |
|---|---|---|
| OOB write via offset corruption | Base log offset field points outside valid region | added_len_check_before_memcpy, added_bounds_check_on_offset, added_index_range_check |
| Heap overflow in container load | Container queue size not validated before copy | added_len_check_before_memcpy, added_index_bounds_check |
| Pool corruption via symbol zone | cbSymbolZone field manipulated to write past allocation | added_index_bounds_check, added_struct_size_validation |
| Pool API hardening | Legacy ExAllocatePoolWithTag without NULL checks | deprecated_pool_api_replacement, pool_allocation_null_check_added |
CVEs
| CVE | Driver | Description | Class | ITW |
|---|---|---|---|---|
| CVE-2024-49138 | clfs.sys |
Heap overflow in LoadContainerQ | Buffer Overflow | Yes |
| CVE-2023-28252 | clfs.sys |
OOB write via corrupted base log offset | Buffer Overflow | Yes |
| CVE-2023-36424 | clfs.sys |
Pool overflow from unvalidated reparse data | Buffer Overflow | No |
| CVE-2022-37969 | clfs.sys |
SignaturesOffset OOB write via corrupted cbSymbolZone | Buffer Overflow | Yes |
Key Drivers
clfs.sys (Common Log File System)
- Role: Kernel log file management subsystem
- Attack vector: Crafted .blf log files opened by standard user
- Recurring pattern: Every CVE involves corrupted metadata fields (offsets, sizes, indexes) in the base log file that bypass validation
- Exploitation: Typically yields pool overflow → adjacent object corruption → arbitrary R/W → token swap → SYSTEM
Exploitation Chain (Typical CLFS)
- Craft a
.blffile with corrupted metadata offset/size - Open the log file from user mode via
CreateLogFile - CLFS parses metadata → heap overflow corrupts adjacent pool allocation
- Adjacent object (e.g., pipe attribute, WNF state data) is controlled
- Use corrupted object for arbitrary R/W primitive
- Overwrite process token → SYSTEM