Hmm so this is quite an interesting one. This is similar to CVE-2021-36963 and CVE-2021-38633, both of which are marked as low complexity for being exploited and which will likely get you SYSTEM access, however if you look at the advisory for this bug at https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36955 it is the only one where the “Exploit Code Maturity” is marked as “Functional” in other words Microsoft has verified that code exists to exploit this vulnerability and it works under most scenarios.

Again this is still only local privilege escalation so this isn’t triggerable remotely, hence why the severity is high due to M.S saying this is easy to form an exploit for and the fact that functional exploit code exists according to M.S, however it isn’t Very High since you still need access to an account on the target to exploit this.

Given that this gives SYSTEM level code access and its not hard to make an exploit for it according to Microsoft I would patch this sooner rather than later along with CVE-2021-36963 and CVE-2021-38633. I am still investigating this deeper to figure out what was patched but here is the list of functions within clfs.sys that I believe were patched as part of fixing this bug:

00012	1c00299b4	private: long CClfsBaseFilePersisted::CreateContainer(struct _UNICODE_STRING const &,unsigned __int64 const &,unsigned long,unsigned char,unsigned char,class CClfsContainer * &)	1c0028824	private: long CClfsBaseFilePersisted::CreateContainer(struct _UNICODE_STRING const &,unsigned __int64 const &,unsigned long,unsigned char,unsigned char,class CClfsContainer * &)	0.990	62	61	Perfect match, same name
00013	1c0029d74	public: long CClfsContainer::Create(struct _UNICODE_STRING &,unsigned __int64 const &,struct _CLFS_FILTER_CONTEXT const &,void * const,unsigned char,unsigned char &)	1c0028bdc	public: long CClfsContainer::Create(struct _UNICODE_STRING &,unsigned __int64 const &,struct _CLFS_FILTER_CONTEXT const &,void * const,unsigned char,unsigned char &)	0.950	50	49	Perfect match, same name
00024	1c0031a68	public: long CClfsBaseFile::GetSymbol(long,unsigned char,struct _CLFS_CLIENT_CONTEXT * *)	1c00308c8	public: long CClfsBaseFile::GetSymbol(long,unsigned char,struct _CLFS_CLIENT_CONTEXT * *)	0.950	14	17	Perfect match, same name
00026	1c0032550	ClfsCreateLogFile	1c00313d0	ClfsCreateLogFile	0.910	169	164	Perfect match, same name
00025	1c0032420	public: long CClfsBaseFile::GetSymbol(long,unsigned long,struct _CLFS_CONTAINER_CONTEXT * *)	1c0031290	public: long CClfsBaseFile::GetSymbol(long,unsigned long,struct _CLFS_CONTAINER_CONTEXT * *)	0.870	17	20	Perfect match, same name
00047	1c004f3d8	private: long CClfsBaseFilePersisted::ExtendMetadataBlockDescriptor(unsigned long,unsigned long)	1c004e238	private: long CClfsBaseFilePersisted::ExtendMetadataBlockDescriptor(unsigned long,unsigned long)	0.740	41	46	Perfect match, same name

More details to come when I get the analysis finished some more.

So far that the function Feature_Servicing_2103c_ClfsStatusPrivilegeNotHeld_31093721__private_IsEnabled() was removed from the new build of clfs.sys, and also from the CClfsBaseFilePersisted::CreateContainer call where it was called from. Now it directly checks the return code from CClfsContainer::Create(_UNICODE_STRING &,unsigned __int64 const &,_CLFS_FILTER_CONTEXT const &,void * const,uchar,uchar &) to see if it returned the status code STATUS_PRIVILEGE_NOT_HELD whereas before it would check the return code of Feature_Servicing_2103c_ClfsStatusPrivilegeNotHeld_31093721__private_IsEnabled() for this status.