November 2025 Patch Tuesday - CLFS
Published:
Patch Diffing
Patch diffing is the process of generating a diff or the difference or changes made to a file or software as a whole, by comparing the bytes of an old and new version of the same file. This process is used by attackers and defenders alike to find out what changes are made in the software in question. In cybersecurity, more often than not, this process is used to find out what flaw/s the new version of the software patched.
Windows Patch Tuesday Diffing
I have been patch diffing windows patches on-and-off throughout the years and it used to involve a lot of work — from downloading .cab files from MSRC to extracting several levels of archive to picking the correct version of the most recent file, not to mention that you have to have a copy of the file with 1 version behind the new file so you can easily see what changed and not get distracted with unrelated changes if, say, your old file is several versions behind the new file.
The C:\Windows\SysWOW64 directory also contains incremental updates on these files. Ideally, you have to have a base file and apply the incremental changes to the file up to the target version of the old and new file.
Luckily for us, m417z created Winbindex. Now, it is trivial to get the old and new versions of a given file. The only thing we worry about now is the actual analysis of the patch diff.
November 2025 Patch Tuesday - CLFS
In the recent November Patch Tuesday, I looked at CVE-2025-60709. The vulnerability is an out-of-bounds read on Common Log File System (CLFS) kernel driver. CLFS is a general-purpose logging subsystem in Windows for high-performance transaction and event logging. There has been several CLFS vulnerabilities reported from the previous months as well largely due to its legacy code. Read about CLFS internals at clfs-docs.
To start patch diffing, I downloaded the latest version of clfs.sys (10.0.19041.6575) from Winbindex as well as the version (10.0.19041.6157) immediately preceding it.
I used to use bindiff in the past but I used ghidriff for patch diffing clfs.sys as it is a lot easier to configure and it diffs the decompiled version (which may or may not be accurate). You can see my ghidriff’s result in clfs.10.0.19041.6157.sys-clfs.10.0.19041.6575.sys.md.
The vulnerability stems from the ClfsGetFirstRecord function as shown below:
ClfsGetFirstRecord Diff
--- ClfsGetFirstRecord
+++ ClfsGetFirstRecord
@@ -1,16 +1,31 @@
/* struct _CLFS_RECORD_HEADER * __ptr64 __cdecl ClfsGetFirstRecord(unsigned char * __ptr64,unsigned
long) */
_CLFS_RECORD_HEADER * __cdecl ClfsGetFirstRecord(uchar *param_1,ulong param_2)
{
uint uVar1;
+ long lVar2;
+ ulonglong uVar3;
+ ulong local_res8 [2];
- if (((param_1 != (uchar *)0x0) && (uVar1 = *(uint *)(param_1 + 0x28), 0x27 < uVar1 + 0x28)) &&
- ((ulonglong)uVar1 <= (ulonglong)param_2 + 0x28)) {
- return (_CLFS_RECORD_HEADER *)(param_1 + uVar1);
+ local_res8[0] = 0;
+ if (param_1 != (uchar *)0x0) {
+ uVar1 = *(uint *)(param_1 + 0x28);
+ uVar3 = Feature_1408008505__private_IsEnabledDeviceUsage();
+ if ((int)uVar3 == 0) {
+ lVar2 = RtlULongAdd(0x28,uVar1,local_res8);
+ if ((-1 < lVar2) && ((ulonglong)uVar1 <= (ulonglong)param_2 + 0x28)) goto LAB_0;
+ }
+ else {
+ lVar2 = RtlULongAdd(0x28,uVar1,local_res8);
+ if ((-1 < lVar2) && ((0x6f < uVar1 && (local_res8[0] <= param_2)))) {
+LAB_0:
+ return (_CLFS_RECORD_HEADER *)(param_1 + uVar1);
+ }
+ }
}
return (_CLFS_RECORD_HEADER *)0x0;
}
Here is the side-by-side comparison.
The diff shows that more validations are made with param_1, which is a buffer, and param_2 which is the size. Both parameters to the function is user-controlled and when validations are bypassed, an attacker can leak sensitive kernel pointers that can later on be fetched as _CLFS_RECORD_HEADER.
Conclusion
Memory leaks like this are used by browser exploits in a goal to break out of sandboxes or other processes that run in low integrity. MSRC states “Out-of-bounds read in Windows Common Log File System Driver allows an authorized attacker to elevate privileges locally.” There might be a way to convert this vulnerability to a full kernel exploit which would be super cool to see or they only meant if this vulnerability is combined with another vulnerability.
In any case, CLFS will continue to be a target of researchers and attackers and new CVEs will be discovered.