Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> keys: Pin request_key_auth payload in instantiate paths<br /> <br /> A: request_key() B: KEYCTL_INSTANTIATE_IOV<br /> ================ =========================<br /> <br /> create auth key<br /> store rka in auth key<br /> wait for helper<br /> get auth key<br /> load rka from auth key<br /> copy user payload<br /> sleep on #PF<br /> <br /> helper completed<br /> detach and free rka<br /> destroy auth key<br /> wake up<br /> use rka-&gt;target_key<br /> **USE-AFTER-FREE**<br /> <br /> Give request_key_auth payloads a refcount. Take a payload reference while<br /> authkey-&gt;sem stabilizes the payload and revocation state. Hold that<br /> reference across the instantiate and reject paths. Drop the auth key<br /> owning reference from revoke and destroy.<br /> <br /> [jarkko: Replaced the first two paragraphs of text with an actual<br /> concurrency scenario.]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KEYS: fix overflow in keyctl_pkey_params_get_2()<br /> <br /> The length for the internal output buffer is calculated incorrectly, which<br /> can result overflow when a too small buffer is provided.<br /> <br /> Fix the bug by allocating internal output with the size of the maximum<br /> length of the cryptographic primitive instead of caller provided size.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gcov: use atomic counter updates to fix concurrent access crashes<br /> <br /> GCC&amp;#39;s GCOV instrumentation can merge global branch counters with loop<br /> induction variables as an optimization. In inflate_fast(), the inner copy<br /> loops get transformed so that the GCOV counter value is loaded multiple<br /> times to compute the loop base address, start index, and end bound. Since<br /> GCOV counters are global (not per-CPU), concurrent execution on different<br /> CPUs causes the counter to change between loads, producing inconsistent<br /> values and out-of-bounds memory writes.<br /> <br /> The crash manifests during IPComp (IP Payload Compression) processing when<br /> inflate_fast() runs concurrently on multiple CPUs:<br /> <br /> BUG: unable to handle page fault for address: ffffd0a3c0902ffa<br /> RIP: inflate_fast+1431<br /> Call Trace:<br /> zlib_inflate<br /> __deflate_decompress<br /> crypto_comp_decompress<br /> ipcomp_decompress [xfrm_ipcomp]<br /> ipcomp_input [xfrm_ipcomp]<br /> xfrm_input<br /> <br /> At the crash point, the compiler generated three loads from the same<br /> global GCOV counter (__gcov0.inflate_fast+216) to compute base, start, and<br /> end for an indexed loop. Another CPU modified the counter between loads,<br /> making the values inconsistent - the write went 3.4 MB past a 65 KB<br /> buffer.<br /> <br /> Add -fprofile-update=prefer-atomic to CFLAGS_GCOV at the global level in<br /> the top-level Makefile, guarded by a try-run compile test. The test<br /> compiles a minimal program with and without -fprofile-update=prefer-atomic<br /> using the full KBUILD_CFLAGS, then compares undefined symbols in the<br /> resulting object files. If prefer-atomic introduces new undefined<br /> references (such as __atomic_fetch_add_8 on i386 or __aarch64_ldadd8_relax<br /> on arm64 with outline-atomics), the flag is not added -- the kernel does<br /> not link against libatomic.<br /> <br /> On architectures where GCC inlines 64-bit atomic counter updates (x86_64,<br /> s390, ...) the test passes and the flag is enabled, preventing the<br /> compiler from merging counters with loop induction variables and fixing<br /> the observed concurrent-access crash.<br /> <br /> On architectures where the flag would introduce libatomic dependencies, it<br /> is silently omitted and behaviour is no worse than before this patch.<br /> <br /> Move the CFLAGS_GCOV block from its original position (before the arch<br /> Makefile include) to after the core KBUILD_CFLAGS assignments but before<br /> the scripts/Makefile.gcc-plugins include. This placement ensures the<br /> try-run test sees arch-specific flags (-m32, -march=,<br /> -mno-outline-atomics) while avoiding GCC plugin flags (-fplugin=) that<br /> would break the test on clean builds when plugin shared objects do not yet<br /> exist.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: fix use-after-free in store_modes()<br /> <br /> store_modes() replaces a framebuffer&amp;#39;s modelist with modes from userspace.<br /> On success it frees the old modelist with fb_destroy_modelist(). Two<br /> fields still point into that freed list.<br /> <br /> One pointer is fb_display[i].mode, the mode a console is using.<br /> fbcon_new_modelist() moves these pointers to the new list. It only does so<br /> for consoles still mapped to the framebuffer. An unmapped console is<br /> skipped and keeps its stale pointer. Unbinding fbcon, for example, sets<br /> con2fb_map[i] to -1 but leaves fb_display[i].mode set. An<br /> FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches<br /> fbcon_mode_deleted(). That function reads the stale fb_display[i].mode<br /> through fb_mode_is_equal(). The read is a use-after-free.<br /> <br /> The other pointer is fb_info-&gt;mode, the current mode. It is set through<br /> the mode sysfs attribute. store_modes() does not update fb_info-&gt;mode, so<br /> it is left pointing into the freed list. show_mode(), the attribute&amp;#39;s read<br /> handler, dereferences the stale fb_info-&gt;mode through mode_string(). The<br /> read is a use-after-free.<br /> <br /> Clear both pointers before freeing the list. Commit a1f305893074 ("fbcon:<br /> Set fb_display[i]-&gt;mode to NULL when the mode is released") added the<br /> helper fbcon_delete_modelist(). It clears every fb_display[i].mode that<br /> points into a given list. So far it is called only from the unregister<br /> path. Call it from store_modes() too, and set fb_info-&gt;mode to NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix use-after-free in rawdata dedup loop<br /> <br /> aa_replace_profiles() walks ns-&gt;rawdata_list to dedup the incoming<br /> policy blob against entries already attached to existing profiles.<br /> Per the kernel-doc on struct aa_loaddata, list membership does not<br /> hold a reference: profiles hold pcount, and when the last pcount<br /> drops, do_ploaddata_rmfs() is queued on a workqueue that takes<br /> ns-&gt;lock and removes the entry. Between dropping the last pcount<br /> and the workqueue running, an entry remains on the list with<br /> pcount == 0.<br /> <br /> aa_get_profile_loaddata() is an unconditional kref_get() on<br /> pcount, so when the dedup loop hits such an entry, refcount<br /> hardening reports<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> <br /> inside aa_replace_profiles(), and the poisoned counter then<br /> trips "saturated" and "underflow" warnings on the subsequent<br /> uses of the same loaddata.<br /> <br /> Before commit a0b7091c4de4 ("apparmor: fix race on rawdata<br /> dereference") the dedup path used a get_unless_zero-style helper<br /> on a single counter, so the existing "if (tmp)" guard was<br /> meaningful. The split-refcount refactor introduced<br /> aa_get_profile_loaddata(), which has plain kref_get() semantics,<br /> and the guard quietly became a no-op.<br /> <br /> Introduce aa_get_profile_loaddata_not0(), matching the existing<br /> _not0 convention used by aa_get_profile_not0(), and use it for<br /> the rawdata_list dedup lookup so dying entries are skipped.<br /> <br /> Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu<br /> 24.04 + stress-ng 0.17.06:<br /> <br /> stress-ng --apparmor 1 --klog-check --timeout 60s<br /> <br /> Without this patch the three refcount_t warnings fire within a<br /> few seconds. With it the same 60 s run is clean. Coverage is a<br /> smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN<br /> and CONFIG_PROVE_LOCKING would be welcome from anyone with the<br /> cycles.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: read COW data with the original inode during atomic write<br /> <br /> When updating an atomic-write file, f2fs_write_begin() may read the<br /> previously written data back from the COW inode:<br /> prepare_atomic_write_begin() locates the block in the COW inode and sets<br /> use_cow, and the read bio is then built with the COW inode:<br /> <br /> f2fs_submit_page_read(use_cow ? F2FS_I(inode)-&gt;cow_inode : inode,<br /> ...);<br /> <br /> and f2fs_grab_read_bio() decides whether to schedule fs-layer decryption<br /> (STEP_DECRYPT) for the bio based on that inode via<br /> fscrypt_inode_uses_fs_layer_crypto().<br /> <br /> However, the folio being filled belongs to the original inode<br /> (folio-&gt;mapping-&gt;host == inode), and the data stored in the COW block was<br /> encrypted (or left as plaintext) using the original inode&amp;#39;s context, not<br /> the COW inode&amp;#39;s -- see f2fs_encrypt_one_page(), which keys off<br /> fio-&gt;page-&gt;mapping-&gt;host. fscrypt_decrypt_pagecache_blocks() likewise<br /> operates on folio-&gt;mapping-&gt;host.<br /> <br /> The COW inode is created as a tmpfile in the parent directory and inherits<br /> its encryption policy from there. With test_dummy_encryption the newly<br /> created COW inode gets the dummy policy and becomes encrypted, while a<br /> pre-existing regular file -- created before the policy applied, e.g.<br /> already present in the on-disk image -- stays unencrypted. The read<br /> path then sets STEP_DECRYPT based on the encrypted COW inode and calls<br /> fscrypt_decrypt_pagecache_blocks() on a folio whose host (the unencrypted<br /> original inode) has a NULL -&gt;i_crypt_info, dereferencing it:<br /> <br /> Oops: general protection fault, probably for non-canonical address ...<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> RIP: 0010:fscrypt_decrypt_pagecache_blocks+0xa0/0x310<br /> Workqueue: f2fs_post_read_wq f2fs_post_read_work<br /> Call Trace:<br /> fscrypt_decrypt_bio+0x1eb/0x340<br /> f2fs_post_read_work+0xba/0x140<br /> process_one_work+0x91c/0x1a40<br /> worker_thread+0x677/0xe90<br /> kthread+0x2bc/0x3a0<br /> <br /> The COW inode is only needed to locate the on-disk block, and that block<br /> address is already resolved into @blkaddr by prepare_atomic_write_begin()<br /> via __find_data_block(cow_inode, ...); f2fs_submit_page_read() then reads<br /> from that physical @blkaddr directly, so the inode argument only selects<br /> the post-read crypto context, not which block is fetched. Reading with<br /> @inode therefore returns the same (latest, not-yet-committed) COW data,<br /> while making both the fs-layer decryption decision and the inline crypto<br /> path use the correct (original inode&amp;#39;s) key.<br /> <br /> With the COW inode no longer used at the read site, the use_cow flag has no<br /> remaining consumer; drop it from f2fs_write_begin() and<br /> prepare_atomic_write_begin().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()<br /> <br /> When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does<br /> not reset the length of the largest extent to 0 and update the inode<br /> folio. Since modifications to the extent tree are disallowed afterward,<br /> the cached largest extent may become stale. This can trigger the<br /> following error in xfstests generic/388:<br /> <br /> F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix<br /> <br /> In the f2fs_drop_inode path, __destroy_extent_node() does not need to<br /> guarantee that et-&gt;node_cnt is 0, because concurrency with writeback<br /> is expected in this path, and writeback may update the extent cache.<br /> <br /> This patch reverts commit ed78aeebef05 ("f2fs: fix node_cnt race between<br /> extent node destroy and writeback"), and remove the unnecessary zero<br /> check of et-&gt;node_cnt.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "f2fs: remove non-uptodate folio from the page cache in move_data_block"<br /> <br /> This reverts commit 9609dd704725a40cd63d915f2ab6c44248a44598.<br /> <br /> The kernel panics are keeping to be reported especially when the f2fs<br /> partition get almost full. By investigation, we find that the reason is<br /> one f2fs page got freed to buddy without being deleted from LRU and the<br /> root cause is the race happened in [2] which is enrolled by this commit.<br /> <br /> There are 3 race processes in this scenario, please find below for their<br /> main activities.<br /> <br /> The changed code in move_data_block() lets the GC path evict the tail-end<br /> folio from the page cache through folio_end_dropbehind(). Once<br /> folio_unmap_invalidate() removes the folio from mapping-&gt;i_pages, the<br /> page-cache references for all pages in the folio are dropped. The folio<br /> is then kept alive only by temporary external references, which allows a<br /> later split to operate on a folio whose subpages are no longer protected<br /> by page-cache references.<br /> <br /> After the page-cache references are gone, split_folio_to_order() can<br /> split the big folio into individual pages and put the resulting subpages<br /> back on the LRU. For tail pages beyond EOF, split removes them from the<br /> page cache and drops their page-cache references. A tail page can then<br /> remain on the LRU with PG_lru set while holding only the split caller&amp;#39;s<br /> temporary reference. When free_folio_and_swap_cache() drops that final<br /> reference, the page enters the final folio_put() release path.<br /> <br /> In parallel, folio_isolate_lru() can observe the same tail page with a<br /> non-zero refcount and PG_lru set. It clears PG_lru before taking its own<br /> reference. If this races with the final folio_put() from the split path,<br /> __folio_put() sees PG_lru already cleared and skips lruvec_del_folio().<br /> The page is then freed back to the allocator while its lru links are<br /> still present in the LRU list. A later LRU operation on a neighboring<br /> page detects the stale link and reports list corruption.<br /> <br /> [1]<br /> [ 22.486082] list_del corruption. next-&gt;prev should be fffffffec10e0ac8, but was dead000000000122. (next=fffffffec10e0a88)<br /> [ 22.486130] ------------[ cut here ]------------<br /> [ 22.486134] kernel BUG at lib/list_debug.c:67!<br /> [ 22.486141] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> [ 22.488502] Tainted: [W]=WARN, [O]=OOT_MODULE<br /> [ 22.488506] Hardware name: Spreadtrum UMS9230 1H10 SoC (DT)<br /> [ 22.488511] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 22.488517] pc : __list_del_entry_valid_or_report+0x14c/0x154<br /> [ 22.488531] lr : __list_del_entry_valid_or_report+0x14c/0x154<br /> [ 22.488539] sp : ffffffc08006b830<br /> [ 22.488542] x29: ffffffc08006b868 x28: 0000000000003020 x27: 0000000000000000<br /> [ 22.488553] x26: 0000000000000000 x25: 0000000000000004 x24: fffffffec10e0ac0<br /> [ 22.488564] x23: 00000000000000e8 x22: 0000000000000024 x21: dead000000000122<br /> [ 22.488574] x20: fffffffec10e0a88 x19: fffffffec10e0ac8 x18: ffffffc080061060<br /> [ 22.488585] x17: 20747562202c3863 x16: 6130653031636566 x15: 0000000000000058<br /> [ 22.488595] x14: 0000000000000004 x13: ffffff80f91e0000 x12: 0000000000000003<br /> [ 22.488605] x11: 0000000000000003 x10: 0000000000000001 x9 : ffe85721f0e25f00<br /> [ 22.488615] x8 : ffe85721f0e25f00 x7 : 0000000000000000 x6 : 6c65645f7473696c<br /> [ 22.488625] x5 : ffffffed39b23026 x4 : 0000000000000000 x3 : 0000000000000010<br /> [ 22.488636] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000006d<br /> [ 22.488647] Call trace:<br /> [ 22.488651] __list_del_entry_valid_or_report+0x14c/0x154 (P)<br /> [ 22.488661] __folio_put+0x2bc/0x434<br /> [ 22.488670] folio_put+0x28/0x58<br /> [ 22.488678] do_garbage_collect+0x1a34/0x2584<br /> [ 22.488689] f2fs_gc+0x230/0x9b4<br /> [ 22.488697] f2fs_fallocate+0xb90/0xdf4<br /> [ 22.488706] vfs_fallocate+0x1b4/0x2bc<br /> [ 22.488716] __arm64_sys_fallocate+0x44/0x78<br /> [ 22.488725] invoke_syscall+0x58/0xe4<br /> [ 22.488732] do_el0_svc+0x48/0xdc<br /> [ 22.488739] el0<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: validate ACL entry sizes in f2fs_acl_from_disk()<br /> <br /> f2fs_acl_count() only validates the aggregate ACL xattr length. A<br /> malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only<br /> contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk()<br /> then reads entry-&gt;e_id before verifying that a full entry fits.<br /> <br /> Require a short entry before reading e_tag and e_perm, and require a<br /> full entry before reading e_id for ACL_USER and ACL_GROUP. Return<br /> -EFSCORRUPTED from these new truncated-entry checks, while keeping the<br /> pre-existing -EINVAL paths unchanged.<br /> <br /> Validation reproduced this kernel report:<br /> KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0<br /> RIP: 0033:0x7f4b835ea7aa<br /> The buggy address belongs to the object at ffff888114589960 which belongs<br /> to the cache kmalloc-8 of size 8<br /> The buggy address is located 0 bytes to the right of allocated 8-byte<br /> region [ffff888114589960, ffff888114589968)<br /> Read of size 4<br /> Call trace:<br /> dump_stack_lvl+0x66/0xa0 (?:?)<br /> print_report+0xce/0x630 (?:?)<br /> __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169)<br /> srso_alias_return_thunk+0x5/0xfbef5 (?:?)<br /> __virt_addr_valid+0x224/0x430 (?:?)<br /> kasan_report+0xe0/0x110 (?:?)<br /> __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169)<br /> __get_acl+0x281/0x380 (?:?)<br /> vfs_get_acl+0x10b/0x190 (?:?)<br /> do_get_acl+0x2a/0x410 (?:?)<br /> do_get_acl+0x9/0x410 (?:?)<br /> do_getxattr+0xe8/0x260 (?:?)<br /> filename_getxattr+0xd1/0x140 (?:?)<br /> do_getname+0x2d/0x2d0 (?:?)<br /> path_getxattrat+0x16c/0x200 (?:?)<br /> lock_release+0xc8/0x290 (?:?)<br /> cgroup_update_frozen+0x9d/0x320 (?:?)<br /> lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?)<br /> trace_hardirqs_on+0x1a/0x170 (?:?)<br /> _raw_spin_unlock_irq+0x28/0x50 (?:?)<br /> do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87)<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: bound i_inline_xattr_size for non-inline-xattr inodes<br /> <br /> When the flexible_inline_xattr feature is enabled, do_read_inode() loads<br /> the on-disk i_inline_xattr_size unconditionally:<br /> <br /> if (f2fs_sb_has_flexible_inline_xattr(sbi))<br /> fi-&gt;i_inline_xattr_size = le16_to_cpu(ri-&gt;i_inline_xattr_size);<br /> <br /> but sanity_check_inode() only range-checks it when the inode also has the<br /> FI_INLINE_XATTR flag set. An inode that carries an inline dentry or inline<br /> data but not FI_INLINE_XATTR -- the normal layout for an inline<br /> directory -- therefore keeps a fully attacker-controlled<br /> i_inline_xattr_size from a crafted image.<br /> <br /> get_inline_xattr_addrs() returns that value with no flag gating, so it<br /> feeds the inode geometry:<br /> <br /> MAX_INLINE_DATA() = 4 * (CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1)<br /> NR_INLINE_DENTRY() = MAX_INLINE_DATA() * BITS_PER_BYTE / (...)<br /> addrs_per_page() = CUR_ADDRS_PER_INODE - i_inline_xattr_size<br /> <br /> A large i_inline_xattr_size drives MAX_INLINE_DATA() and NR_INLINE_DENTRY()<br /> negative, so make_dentry_ptr_inline() sets d-&gt;max (int) to a negative<br /> value. The inline directory walk then compares an unsigned long bit_pos<br /> against that negative d-&gt;max, which is promoted to a huge unsigned bound,<br /> and reads far past the inline area:<br /> <br /> while (bit_pos max) /* fs/f2fs/dir.c */<br /> ... test_bit_le(bit_pos, d-&gt;bitmap) / d-&gt;dentry[bit_pos] ...<br /> <br /> Mounting a crafted image and reading such a directory triggers an<br /> out-of-bounds read in f2fs_fill_dentries(); the same underflow also<br /> corrupts ADDRS_PER_INODE for regular files.<br /> <br /> Validate i_inline_xattr_size against MAX_INLINE_XATTR_SIZE whenever the<br /> flexible_inline_xattr feature is enabled -- i.e. whenever the value is<br /> loaded from disk and consumed -- and keep the lower MIN_INLINE_XATTR_SIZE<br /> bound gated on inodes that actually carry an inline xattr, so legitimate<br /> inodes with i_inline_xattr_size == 0 are still accepted.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode<br /> <br /> - ioctl(F2FS_IOC_GARBAGE_COLLECT_RANGE) - shrink<br /> - f2fs_gc<br /> - gc_data_segment<br /> - ra_data_block(cow_inode)<br /> - mapping = F2FS_I(inode)-&gt;atomic_inode-&gt;i_mapping<br /> : f2fs_is_cow_file(cow_inode) is true<br /> - f2fs_evict_inode(atomic_inode)<br /> - clear_inode_flag(fi-&gt;cow_inode, FI_COW_FILE)<br /> - F2FS_I(fi-&gt;cow_inode)-&gt;atomic_inode = NULL<br /> ...<br /> - truncate_inode_pages_final(atomic_inode)<br /> - f2fs_grab_cache_folio(mapping)<br /> : create folio in atomic_inode-&gt;mapping<br /> - clear_inode(atomic_inode)<br /> - BUG_ON(atomic_inode-&gt;i_data.nrpages)<br /> <br /> We need to add a reference on fi-&gt;atomic_inode before using its mapping<br /> field during garbage collection, otherwise, it will cause UAF issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: validate compress cache inode only when enabled<br /> <br /> F2FS_COMPRESS_INO() uses NM_I(sbi)-&gt;max_nid as the synthetic inode<br /> number for the compressed page cache inode. That inode only exists when<br /> the compress_cache mount option is enabled.<br /> <br /> When compress_cache is disabled, max_nid is outside the valid inode<br /> range. A corrupted directory entry that points to ino == max_nid should<br /> therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino()<br /> currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally,<br /> so f2fs_iget() bypasses do_read_inode() and its nid range check, and<br /> instantiates a fake internal inode instead.<br /> <br /> Gate the compressed cache inode case on COMPRESS_CACHE, matching<br /> f2fs_init_compress_inode(). With compress_cache disabled, ino ==<br /> max_nid now follows the normal inode path and is rejected as an<br /> out-of-range nid.