In the Linux kernel, the following vulnerability has been resolved:

ocfs2: reject oversized group bitmap descriptors

ocfs2validategdparent() only bounds bgbits against the parent allocator's chain geometry. A malicious descriptor can still claim a bgsize/bgbits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bgbitmap.

Add a physical-cap check based on ocfs2groupbitmapsize() for the parent allocator type and reject descriptors whose bgsize or bgbits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used.

Validation reproduced this kernel report: KASAN use-after-free in findnextbit+0x7f/0xc0 Read of size 8 Call trace: dumpstacklvl+0x66/0xa0 (?:?) printreport+0xd0/0x630 (?:?) findnextbit+0x7f/0xc0 (?:?) srsoaliasreturnthunk+0x5/0xfbef5 (?:?) virtaddrvalid+0x188/0x2f0 (?:?) kasanreport+0xe4/0x120 (?:?) ocfs2findmaxcontigfreebits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2blockgroupsetbits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2clustergroupsearch+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2bgdiscontigfixresult+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2searchchain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) getpagefromfreelist+0x70e/0x2370 (?:?) lockrelease+0xc6/0x290 (?:?) dorawspinunlock+0x9a/0x100 (?:?) kasanunpoison+0x27/0x60 (?:?) bfs+0x147/0x240 (?:?) getpagefromfreelist+0x83d/0x2370 (?:?) ocfs2claimsuballocbits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) scheddomainsnumamasksclear+0x70/0xd0 (?:?) checkirqusage+0xe8/0xb70 (?:?) ocfs2claimclusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) checkpath+0x24/0x50 (?:?) rcuiswatching+0x20/0x50 (?:?) checkprevadd+0xfd/0xd00 (?:?) ocfs2addclustersinbtree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) foliobatchaddandmove+0x1f5/0x3d0 (?:?) ocfs2addinodedata+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemapaddfolio+0x105/0x1f0 (?:?) ocfs2writebeginnolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2readinodeblock+0xb5/0x110 (fs/ocfs2/suballoc.c:?) downwrite+0xf5/0x180 (?:?) ocfs2writebegin+0x180/0x240 (fs/ocfs2/suballoc.c:?) markinodedirty+0x758/0x9a0 (?:?) inodetobdi+0x41/0x90 (?:?) balancedirtypagesratelimitedflags+0xf8/0x1d0 (?:?) genericperformwrite+0x252/0x440 (?:?) mntputwriteaccessfile+0x16/0x70 (?:?) fileupdatetimeflags+0xe4/0x200 (?:?) ocfs2filewriteiter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lockacquire+0x184/0x2f0 (?:?) ksyswrite+0xd2/0x170 (?:?) apparmorfilepermission+0xf5/0x310 (?:?) readzero+0x8d/0x140 (?:?) lockisheldtype+0x8f/0x100 (?:?)

In the Linux kernel, the following vulnerability has been resolved:

ocfs2: validate inline data isize during inode read

When reading an inode from disk, ocfs2validateinodeblock() performs various sanity checks but does not validate the size of inline data. If the filesystem is corrupted, an inode's isize can exceed the actual inline data capacity (idcount).

This causes ocfs2dirforeachblkid() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory.

In the syzbot report: - isize was 1099511627576 bytes (~1TB) - Actual inline data capacity (idcount) is typically <256 bytes - A garbage reclen (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2checkdirentry()

Fix by adding a validation check in ocfs2validateinodeblock() to ensure inodes with inline data have isize <= idcount. This catches the corruption early during inode read and prevents all downstream code from operating on invalid data.

In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix out-of-bounds write in ocfs2writeendinline

KASAN reports a use-after-free write of 4086 bytes in ocfs2writeendinline, called from ocfs2writeendnolock during a copyfilerange splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF.

The root cause is that ocfs2trytowriteinlinedata trusts the on-disk idcount field to determine whether a write fits in inline data. On a corrupted filesystem, idcount can exceed the physical maximum inline data capacity, causing writes to overflow the inode block buffer.

Call trace (crash path):

vfscopyfilerange (fs/readwrite.c:1634) dosplicedirect splicedirecttoactor iterfilesplicewrite ocfs2filewriteiter genericperformwrite ocfs2writeend ocfs2writeendnolock (fs/ocfs2/aops.c:1949) ocfs2writeendinline (fs/ocfs2/aops.c:1915) memcpyfromfolio <-- KASAN: write OOB

So add idcount upper bound check in ocfs2validateinodeblock() to alongside the existing isize check to fix it.

In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix possible deadlock between unlink and dioendiowrite

ocfs2unlink takes orphan dir inodelock first and then ipallocsem, while in ocfs2dioendiowrite, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2sysfilelockkey[ORPHANDIRSYSTEMINODE] and ocfs2fileipallocsemkey.

Lock Chain #0 (orphan dir inodelock -> ipallocsem): ocfs2unlink ocfs2prepareorphandir ocfs2lookuplockorphandir inodelock(orphandirinode) <- lock A ocfs2prepareorphandir ocfs2preparedirforinsert ocfs2extenddir ocfs2expandinlinedir downwrite(&oi->ipallocsem) <- Lock B

Lock Chain #1 (ipallocsem -> orphan dir inodelock): ocfs2dioendiowrite downwrite(&oi->ipallocsem) <- Lock B ocfs2delinodefromorphan() inodelock(orphandirinode) <- Lock A

Deadlock Scenario: CPU0 (unlink) CPU1 (dioendiowrite) ------ ------ inodelock(orphandirinode) downwrite(ipallocsem) downwrite(ipallocsem) inodelock(orphandirinode)

Since ipallocsem is to protect allocation changes, which is unrelated with operations in ocfs2delinodefromorphan. So move ocfs2delinodefromorphan out of ipallocsem to fix the deadlock.

In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix use-after-free in ocfs2fault() when VMFAULTRETRY

filemapfault() may drop the mmaplock before returning VMFAULTRETRY, as documented in mm/filemap.c:

"If our return value has VMFAULTRETRY set, it's because the mmaplock may be dropped before doing I/O or by lockfoliomaybedropmmap()."

When this happens, a concurrent munmap() can call removevma() and free the vmareastruct via RCU. The saved 'vma' pointer in ocfs2fault() then becomes a dangling pointer, and the subsequent traceocfs2fault() call dereferences it -- a use-after-free.

Fix this by saving ipblkno as a plain integer before calling filemapfault(), and removing vma from the trace event. Since ipblkno is copied by value before the lock can be dropped, it remains valid regardless of what happens to the vma or inode afterward.