CVE-2026-89496: ocfs2: always run deallocs on copy-on-write completion
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: always run deallocs on copy-on-write completion
Local fuzzing of 6.12.94 has found the following memory leak caused by doing 'copyfilerange()' within the same filesystem:
unreferenced object 0xffff88812192c980 (size 32): comm "syz.0.49", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 ................ c0 c5 92 21 81 88 ff ff 00 02 00 00 00 06 00 00 ...!............ backtrace (crc 7068d63f): kmemleakallocrecursive include/linux/kmemleak.h:42 [inline] slabpostallochook mm/slub.c:4152 [inline] slaballocnode mm/slub.c:4197 [inline] kmalloccachenoprof+0x168/0x2c0 mm/slub.c:4358 kmallocnoprof include/linux/slab.h:878 [inline] ocfs2findperslotfreelist fs/ocfs2/alloc.c:6618 [inline] ocfs2cacheblockdealloc+0x155/0x4b0 fs/ocfs2/alloc.c:6786 ocfs2cacheextentblockfree fs/ocfs2/alloc.c:6819 [inline] ocfs2unlinkpath+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2rotatesubtreeleft fs/ocfs2/alloc.c:2779 [inline] ocfs2rotatetreeleft+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2rotatetreeleft+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2trytomergeextent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2splitextent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2clearextrefcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2replaceclusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2makeclusterswritable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2replacecow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2refcountcowhunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2refcountcow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2prepareinodeforwrite fs/ocfs2/file.c:2340 [inline] ocfs2filewriteiter+0xbda/0x1880 fs/ocfs2/file.c:2451 iterfilesplicewrite+0x890/0xf60 fs/splice.c:743 dosplicefrom fs/splice.c:944 [inline] directspliceactor+0x232/0x480 fs/splice.c:1167 splicedirecttoactor+0x4b4/0xb60 fs/splice.c:1111 dosplicedirectactor fs/splice.c:1210 [inline] dosplicedirect+0x10f/0x1c0 fs/splice.c:1236 dosendfile+0x430/0xbf0 fs/readwrite.c:1388
unreferenced object 0xffff88812192c5c0 (size 32): comm "syz.0.49", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 29 70 00 00 00 00 00 00 19 00 00 00 00 00 00 00 )p.............. backtrace (crc afec850f): kmemleakallocrecursive include/linux/kmemleak.h:42 [inline] slabpostallochook mm/slub.c:4152 [inline] slaballocnode mm/slub.c:4197 [inline] kmalloccachenoprof+0x168/0x2c0 mm/slub.c:4358 kmallocnoprof include/linux/slab.h:878 [inline] kzallocnoprof include/linux/slab.h:1014 [inline] ocfs2cacheblockdealloc+0x25c/0x4b0 fs/ocfs2/alloc.c:6793 ocfs2cacheextentblockfree fs/ocfs2/alloc.c:6819 [inline] ocfs2unlinkpath+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2rotatesubtreeleft fs/ocfs2/alloc.c:2779 [inline] ocfs2rotatetreeleft+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2rotatetreeleft+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2trytomergeextent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2splitextent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2clearextrefcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2replaceclusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2makeclusterswritable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2replacecow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2refcountcowhunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2refcountcow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2prepareinodeforwrite fs/ocfs2/file.c:2340 [inline] ocfs2filewriteiter+0xbda/0x1880 fs/ocfs2/file.c:2451 iterfilesplicewrite+0x890/0xf60 fs/splice.c:743 dosplicefrom fs/splice.c:9 ---truncated---
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.12.94
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel OCFS2 filesystem are relevant. The reported trigger involves copy_file_range() between files within the same filesystem.
What is required to trigger the leak?
The available report identifies local fuzzing as the discovery method and reproduces the leak through copy_file_range() on the same filesystem. It does not provide evidence of remote exploitation or a required privilege level.
How can I determine whether a system is affected?
Check whether OCFS2 is in use and whether workloads perform same-filesystem copy_file_range() operations. The report detected an unreferenced allocation through kmemleak, with the allocation path involving OCFS2 block deallocation during copy-on-write completion.
What should be done if patching cannot happen immediately?
Where operationally feasible, avoid same-filesystem copy_file_range() workloads on OCFS2 until the relevant kernel fix is deployed. Monitor affected systems for memory leaks if those operations cannot be avoided.