CVE-2026-89834: f2fs: fix to migrate all curseg types during free_segment_range
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to migrate all curseg types during freesegmentrange
In freesegmentrange(), the curseg evacuation loop only iterates up to NRCURSEGPERSISTTYPE (0..5), missing non-persistent in-memory curseg types such as CURSEGCOLDDATAPINNED and CURSEGALLDATAATGC.
Even though these in-memory curseg types are not saved in the on-disk checkpoint header, they still occupy active physical segments at runtime. If an active in-memory curseg happens to be allocated within the segment range being truncated during filesystem shrink, failing to evacuate it will cause subsequent writes to the curseg attempting out-of-bounds I/O on the truncated storage range.
Fix this by expanding the curseg evacuation loop upper bound to NRCURSEGTYPE to ensure all active curseg types are safely migrated out of the target range.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.111-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.111-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.110 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.51 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.5 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Configuration
Expand the curseg evacuation loop upper bound from NR_CURSEG_PERSIST_TYPE to NR_CURSEG_TYPE so all active in-memory curseg types, including CURSEG_COLD_DATA_PINNED and CURSEG_ALL_DATA_ATGC, are migrated out of the target range.
Linux kernel f2fs free_segment_range() curseg evacuation loop upper bound = NR_CURSEG_TYPE
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the Linux kernel F2FS filesystem are exposed when an active non-persistent in-memory curseg type resides in the segment range being truncated during a filesystem shrink.
What operation triggers the vulnerable condition?
The condition occurs during filesystem shrink when free_segment_range() truncates a range containing an active in-memory curseg type that the evacuation loop does not migrate. Subsequent writes through that curseg can then attempt out-of-bounds I/O on the truncated range.
How can this be mitigated if the fix cannot be applied immediately?
The provided information identifies filesystem shrink and truncation of segment ranges as the triggering operation. Avoiding F2FS shrink operations prevents the described path from being exercised.
How can administrators determine whether they may have encountered this issue?
The described symptom is subsequent writes attempting out-of-bounds I/O after an F2FS filesystem shrink. The data does not provide a specific log message, detection command, or affected-version list.