In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
ocfs2: validate rl_used against rl_count in refcount block validator<\/p>\n
ocfs2_find_refcount_rec_in_rl() walks the on-disk refcount record array
\nwith:<\/p>\n
\tfor (; i rf_records.rl_used); i++) {
\n\t\trec = &rb->rf_records.rl_recs[i];
\n\t\t…<\/p>\n
rl_recs[] lives in a single metadata block (4096 bytes on the common
\nconfiguration), so its real capacity is fixed by
\nocfs2_refcount_recs_per_rb(sb) (247 records for a 4K block with the
\n16-byte ocfs2_refcount_rec). rl_used and rl_count are both read directly
\noff disk by ocfs2_validate_refcount_block() and are never checked against
\nthat capacity, nor against each other, before any refcount\/reflink\/CoW
\noperation walks the array.<\/p>\n
A crafted (or corrupted) refcount block with rl_used == 0xffff makes the
\nloop above walk far past the end of the block, dereferencing rl_recs[i]
\nfor i up to 65534. The resulting index is then handed to the sibling
\nocfs2_insert_refcount_rec(), whose insert-shift does:<\/p>\n
\tif (index rl_used))
\n\t\tmemmove(&rf_list->rl_recs[index + 1],
\n\t\t\t&rf_list->rl_recs[index],
\n\t\t\t(le16_to_cpu(rf_list->rl_used) – index) *
\n\t\t\t sizeof(struct ocfs2_refcount_rec));<\/p>\n
i.e. a memmove() of up to (0xffff – index) * 16 bytes (~1 MiB) from an
\noffset already past the block. This is reachable from an ordinary reflink
\n(FICLONE) against a crafted\/corrupted ocfs2 image: attaching an extent
\nwhose cpos sorts past every real record in the leaf forces the lookup to
\nrun off the end instead of returning early on a match. The attacker model
\nis local: CAP_SYS_ADMIN mounting a crafted or corrupted ocfs2 image, or a
\nraw write to the block device backing an already-mounted ocfs2 filesystem.<\/p>\n
ocfs2_validate_refcount_block() already validates the block’s ECC,
\nsignature, rf_blkno and rf_fs_generation, but never rl_count\/rl_used
\nagainst the block’s actual on-disk capacity. This is the same class of
\ngap that ocfs2_validate_extent_block() (fs\/ocfs2\/alloc.c) already closes
\nfor the sibling extent-list header, which checks both the record capacity
\nand the “used” bound before any code walks h_list.l_recs[]:<\/p>\n
\tif (le16_to_cpu(eb->h_list.l_count) != ocfs2_extent_recs_per_eb(sb)) {
\n\t\trc = ocfs2_error(…);
\n\t\tgoto bail;
\n\t}<\/p>\n
\tif (le16_to_cpu(eb->h_list.l_next_free_rec) >
\n\t le16_to_cpu(eb->h_list.l_count)) {
\n\t\trc = ocfs2_error(…);
\n\t\tgoto bail;
\n\t}<\/p>\n
Add the equivalent pair of checks to ocfs2_validate_refcount_block():
\nreject a refcount block whose rl_count does not match the fixed per-block
\ncapacity returned by ocfs2_refcount_recs_per_rb(), and reject rl_used >
\nrl_count. Both checks are skipped when OCFS2_REFCOUNT_TREE_FL is set,
\nbecause in that case the same union bytes hold an ocfs2_extent_list
\n(rf_list), not the refcount record list (rf_records) — that layout is
\nalready validated separately by ocfs2_validate_extent_block() when the
\nreferenced extent block is read. This mirrors the existing
\n“!(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL)” guard used elsewhere in this
\nfile (e.g. ocfs2_get_refcount_rec()) to decide whether rf_records or
\nrf_list is the live member of the union.<\/p>\n
With this in place, a forged rl_used\/rl_count is caught at block
\nvalidation time (ocfs2_error()), consistent with every other corruption
\ncheck in this function, instead of driving an out-of-bounds read in
\nocfs2_find_refcount_rec_in_rl() and a subsequent out-of-bounds memmove()
\nin ocfs2_insert_refcount_rec().<\/p>\n
Verified against a crafted image on a v6.19 KASAN (KASAN_GENERIC) build:
\nreplaying the same reflink (FICLONE) reliably hit a KASAN report in
\n__ocfs2_increase_refcount()\/ocfs2_insert_refcount_rec() before this patch,
\nand triggers no report once ocfs2_validate_refcount_block() rejects the
\nforged rl_used\/rl_count.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
ocfs2: validate rl_used against rl_count in refcount block validator<\/p>\n
ocfs2_find_refcount_rec_in_rl() walks the on-disk refcount re<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-21415","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/21415","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21415"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21415"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21415"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}