CVE-2026-63819

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

f2fs: fix to do sanity check on f2fsgetnodefoliora()

kernel BUG at fs/f2fs/file.c:845! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5336 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:f2fsdotruncateblocks+0x1115/0x1140 fs/f2fs/file.c:845 Code: fc fc 90 0f 0b e8 8b 9d 9a fd 90 0f 0b e8 83 9d 9a fd 48 89 df 48 c7 c6 60 d1 1a 8c e8 54 f1 fc fc 90 0f 0b e8 6c 9d 9a fd 90 <0f> 0b e8 64 9d 9a fd 90 0f 0b 90 e9 93 fd ff ff e8 56 9d 9a fd 90 RSP: 0018:ffffc9000e4474c0 EFLAGS: 00010283 RAX: ffffffff842b1d34 RBX: 0000000000000003 RCX: 0000000000100000 RDX: ffffc9000f03a000 RSI: 0000000000035503 RDI: 0000000000035504 RBP: ffffc9000e447608 R08: ffff8880123b0000 R09: 0000000000000002 R10: 00000000fffffffe R11: 0000000000000002 R12: 0000000000000001 R13: 0000000000000000 R14: 1ffff92001c88ea0 R15: 00000000ffff039c FS: 00007f7e02ee36c0(0000) GS:ffff88808c887000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff0305c4000 CR3: 0000000012d4c000 CR4: 0000000000352ef0 Call Trace: <TASK> f2fstruncateblocks+0x10a/0x300 fs/f2fs/file.c:882 f2fstruncate+0x471/0x7c0 fs/f2fs/file.c:940 f2fsevictinode+0xa3f/0x1ac0 fs/f2fs/inode.c:907 evict+0x61e/0xb10 fs/inode.c:841 f2fsfillsuper+0x5f43/0x78f0 fs/f2fs/super.c:5224 gettreebdevflags+0x431/0x4f0 fs/super.c:1694 vfsgettree+0x92/0x2a0 fs/super.c:1754 fcmount fs/namespace.c:1193 [inline] donewmountfc fs/namespace.c:3758 [inline] donewmount+0x341/0xd30 fs/namespace.c:3834 domount fs/namespace.c:4167 [inline] __dosysmount fs/namespace.c:4383 [inline] __sesysmount+0x31d/0x420 fs/namespace.c:4360 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x15f/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

count = ADDRS_PER_PAGE(dn.node_folio, inode);

count -= dn.ofs_in_node;
f2fs_bug_on(sbi, count < 0);

The fuzz test will trigger above bug_on in f2fs.

The root cause should be: in the corrupted inode, there is a direct node which has the same ino and nid in its footer, so in f2fsdotruncateblocks(), after f2fsgetdnodeofdata() finds such dnode: 1) ADDRSPERPAGE(dn.nodefolio, inode) will return 923 2) once dn.ofsinnode points to addr[923, 1017] Then it will trigger the system panic.

Let's introduce NODETYPENON_IXNODE to indicate current node should not be an inode or xattr node, and then use it in below path to detect inconsistent node chain in inode mapping table:

• f2fsdotruncateblocks
  • f2fsgetdnodeofdata
    • f2fsgetnodefoliora
      • getnodefolio
        • f2fssanitychecknodefooter
          • case NODETYPENONIXNODE -> check whether it is inode|xnode