Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: memleak flow rule from commit path<br /> <br /> Abort path release flow rule object, however, commit path does not.<br /> Update code to destroy these objects before releasing the transaction.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panfrost: Job should reference MMU not file_priv<br /> <br /> For a while now it&amp;#39;s been allowed for a MMU context to outlive it&amp;#39;s<br /> corresponding panfrost_priv, however the job structure still references<br /> panfrost_priv to get hold of the MMU context. If panfrost_priv has been<br /> freed this is a use-after-free which I&amp;#39;ve been able to trigger resulting<br /> in a splat.<br /> <br /> To fix this, drop the reference to panfrost_priv in the job structure<br /> and add a direct reference to the MMU structure which is what&amp;#39;s actually<br /> needed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on total_data_blocks<br /> <br /> As Yanming reported in bugzilla:<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=215916<br /> <br /> The kernel message is shown below:<br /> <br /> kernel BUG at fs/f2fs/segment.c:2560!<br /> Call Trace:<br /> allocate_segment_by_default+0x228/0x440<br /> f2fs_allocate_data_block+0x13d1/0x31f0<br /> do_write_page+0x18d/0x710<br /> f2fs_outplace_write_data+0x151/0x250<br /> f2fs_do_write_data_page+0xef9/0x1980<br /> move_data_page+0x6af/0xbc0<br /> do_garbage_collect+0x312f/0x46f0<br /> f2fs_gc+0x6b0/0x3bc0<br /> f2fs_balance_fs+0x921/0x2260<br /> f2fs_write_single_data_page+0x16be/0x2370<br /> f2fs_write_cache_pages+0x428/0xd00<br /> f2fs_write_data_pages+0x96e/0xd50<br /> do_writepages+0x168/0x550<br /> __writeback_single_inode+0x9f/0x870<br /> writeback_sb_inodes+0x47d/0xb20<br /> __writeback_inodes_wb+0xb2/0x200<br /> wb_writeback+0x4bd/0x660<br /> wb_workfn+0x5f3/0xab0<br /> process_one_work+0x79f/0x13e0<br /> worker_thread+0x89/0xf60<br /> kthread+0x26a/0x300<br /> ret_from_fork+0x22/0x30<br /> RIP: 0010:new_curseg+0xe8d/0x15f0<br /> <br /> The root cause is: ckpt.valid_block_count is inconsistent with SIT table,<br /> stat info indicates filesystem has free blocks, but SIT table indicates<br /> filesystem has no free segment.<br /> <br /> So that during garbage colloection, it triggers panic when LFS allocator<br /> fails to find free segment.<br /> <br /> This patch tries to fix this issue by checking consistency in between<br /> ckpt.valid_block_count and block accounted from SIT.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check for inline inode<br /> <br /> Yanming reported a kernel bug in Bugzilla kernel [1], which can be<br /> reproduced. The bug message is:<br /> <br /> The kernel message is shown below:<br /> <br /> kernel BUG at fs/inode.c:611!<br /> Call Trace:<br /> evict+0x282/0x4e0<br /> __dentry_kill+0x2b2/0x4d0<br /> dput+0x2dd/0x720<br /> do_renameat2+0x596/0x970<br /> __x64_sys_rename+0x78/0x90<br /> do_syscall_64+0x3b/0x90<br /> <br /> [1] https://bugzilla.kernel.org/show_bug.cgi?id=215895<br /> <br /> The bug is due to fuzzed inode has both inline_data and encrypted flags.<br /> During f2fs_evict_inode(), as the inode was deleted by rename(), it<br /> will cause inline data conversion due to conflicting flags. The page<br /> cache will be polluted and the panic will be triggered in clear_inode().<br /> <br /> Try fixing the bug by doing more sanity checks for inline data inode in<br /> sanity_check_inode().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Fix potential use-after-free in nfsd_file_put()<br /> <br /> nfsd_file_put_noref() can free @nf, so don&amp;#39;t dereference @nf<br /> immediately upon return from nfsd_file_put_noref().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on block address in f2fs_do_zero_range()<br /> <br /> As Yanming reported in bugzilla:<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=215894<br /> <br /> I have encountered a bug in F2FS file system in kernel v5.17.<br /> <br /> I have uploaded the system call sequence as case.c, and a fuzzed image can<br /> be found in google net disk<br /> <br /> The kernel should enable CONFIG_KASAN=y and CONFIG_KASAN_INLINE=y. You can<br /> reproduce the bug by running the following commands:<br /> <br /> kernel BUG at fs/f2fs/segment.c:2291!<br /> Call Trace:<br /> f2fs_invalidate_blocks+0x193/0x2d0<br /> f2fs_fallocate+0x2593/0x4a70<br /> vfs_fallocate+0x2a5/0xac0<br /> ksys_fallocate+0x35/0x70<br /> __x64_sys_fallocate+0x8e/0xf0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The root cause is, after image was fuzzed, block mapping info in inode<br /> will be inconsistent with SIT table, so in f2fs_fallocate(), it will cause<br /> panic when updating SIT with invalid blkaddr.<br /> <br /> Let&amp;#39;s fix the issue by adding sanity check on block address before updating<br /> SIT table with it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid cycles in directory h-tree<br /> <br /> A maliciously corrupted filesystem can contain cycles in the h-tree<br /> stored inside a directory. That can easily lead to the kernel corrupting<br /> tree nodes that were already verified under its hands while doing a node<br /> split and consequently accessing unallocated memory. Fix the problem by<br /> verifying traversed block numbers are unique.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Fix a data-race in unix_dgram_peer_wake_me().<br /> <br /> unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`&amp;#39;s<br /> lock held and check if its receive queue is full. Here we need to<br /> use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise<br /> KCSAN will report a data-race.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: xfrm: unexport __init-annotated xfrm4_protocol_init()<br /> <br /> EXPORT_SYMBOL and __init is a bad combination because the .init.text<br /> section is freed up after the initialization. Hence, modules cannot<br /> use symbols annotated __init. The access to a freed symbol may end up<br /> with kernel panic.<br /> <br /> modpost used to detect it, but it has been broken for a decade.<br /> <br /> Recently, I fixed modpost so it started to warn it again, then this<br /> showed up in linux-next builds.<br /> <br /> There are two ways to fix it:<br /> <br /> - Remove __init<br /> - Remove EXPORT_SYMBOL<br /> <br /> I chose the latter for this case because the only in-tree call-site,<br /> net/ipv4/xfrm4_policy.c is never compiled as modular.<br /> (CONFIG_XFRM is boolean)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: lantiq_gswip: Fix refcount leak in gswip_gphy_fw_list<br /> <br /> Every iteration of for_each_available_child_of_node() decrements<br /> the reference count of the previous node.<br /> when breaking early from a for_each_available_child_of_node() loop,<br /> we need to explicitly call of_node_put() on the gphy_fw_np.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix bug_on in ext4_writepages<br /> <br /> we got issue as follows:<br /> EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/ext4/inode.c:2708!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155<br /> RIP: 0010:ext4_writepages+0x1977/0x1c10<br /> RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000<br /> RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002<br /> RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000<br /> R10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001<br /> R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028<br /> FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> do_writepages+0x130/0x3a0<br /> filemap_fdatawrite_wbc+0x83/0xa0<br /> filemap_flush+0xab/0xe0<br /> ext4_alloc_da_blocks+0x51/0x120<br /> __ext4_ioctl+0x1534/0x3210<br /> __x64_sys_ioctl+0x12c/0x170<br /> do_syscall_64+0x3b/0x90<br /> <br /> It may happen as follows:<br /> 1. write inline_data inode<br /> vfs_write<br /> new_sync_write<br /> ext4_file_write_iter<br /> ext4_buffered_write_iter<br /> generic_perform_write<br /> ext4_da_write_begin<br /> ext4_da_write_inline_data_begin -&gt; If inline data size too<br /> small will allocate block to write, then mapping will has<br /> dirty page<br /> ext4_da_convert_inline_data_to_extent -&gt;clear EXT4_STATE_MAY_INLINE_DATA<br /> 2. fallocate<br /> do_vfs_ioctl<br /> ioctl_preallocate<br /> vfs_fallocate<br /> ext4_fallocate<br /> ext4_convert_inline_data<br /> ext4_convert_inline_data_nolock<br /> ext4_map_blocks -&gt; fail will goto restore data<br /> ext4_restore_inline_data<br /> ext4_create_inline_data<br /> ext4_write_inline_data<br /> ext4_set_inode_state -&gt; set inode EXT4_STATE_MAY_INLINE_DATA<br /> 3. writepages<br /> __ext4_ioctl<br /> ext4_alloc_da_blocks<br /> filemap_flush<br /> filemap_fdatawrite_wbc<br /> do_writepages<br /> ext4_writepages<br /> if (ext4_has_inline_data(inode))<br /> BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))<br /> <br /> The root cause of this issue is we destory inline data until call<br /> ext4_writepages under delay allocation mode. But there maybe already<br /> convert from inline to extent. To solve this issue, we call<br /> filemap_flush first..

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: filter out EXT4_FC_REPLAY from on-disk superblock field s_state<br /> <br /> The EXT4_FC_REPLAY bit in sbi-&gt;s_mount_state is used to indicate that<br /> we are in the middle of replay the fast commit journal. This was<br /> actually a mistake, since the sbi-&gt;s_mount_info is initialized from<br /> es-&gt;s_state. Arguably s_mount_state is misleadingly named, but the<br /> name is historical --- s_mount_state and s_state dates back to ext2.<br /> <br /> What should have been used is the ext4_{set,clear,test}_mount_flag()<br /> inline functions, which sets EXT4_MF_* bits in sbi-&gt;s_mount_flags.<br /> <br /> The problem with using EXT4_FC_REPLAY is that a maliciously corrupted<br /> superblock could result in EXT4_FC_REPLAY getting set in<br /> s_mount_state. This bypasses some sanity checks, and this can trigger<br /> a BUG() in ext4_es_cache_extent(). As a easy-to-backport-fix, filter<br /> out the EXT4_FC_REPLAY bit for now. We should eventually transition<br /> away from EXT4_FC_REPLAY to something like EXT4_MF_REPLAY.