Check your ntfs3 implementation for run_get_highest_vcn() in fs/ntfs3/run.c. The function processes NTFS run-length encoded data from the mapping-pairs buffer without validating that the VCN stays within the allocated run array bounds — a gap its sibling function run_unpack() had fixed eight months prior in commit b62567bca474. The result is a deterministic kernel panic when mounting a crafted NTFS volume with a malicious $LogFile.
If you run ntfs3 in production, verify the fix is present. The vulnerability requires mounting an attacker-supplied volume — this isn't a remote trigger, and for servers that don't mount untrusted media, the actual exploitation surface is narrow. The CVSS 8.4 score reflects impact if triggered, but the EPSS 0.00154 probability score better reflects the realistic likelihood. Prioritize based on whether your threat model includes malicious volume mounting.
The more important question is how many other ntfs3 run-handling functions lack analogous bounds checks. run_unpack() and run_get_highest_vcn() walk the same mapping-pairs buffer with run headers — if one needed validation, the other should have been flagged. The pattern suggests other functions using run-length encoding (check run_decompress() and any fslog.c variants) may carry the same gap. Audit all functions that walk packed run structures in the ntfs3 subsystem; don't assume the run_unpack() patch covered the entire attack surface.