Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe<br /> <br /> of_find_device_by_node() takes reference, we should use put_device()<br /> to release it when not need anymore.<br /> Add missing put_device() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: Trap RDMA segment overflows<br /> <br /> Prevent svc_rdma_build_writes() from walking off the end of a Write<br /> chunk&amp;#39;s segment array. Caught with KASAN.<br /> <br /> The test that this fix replaces is invalid, and might have been left<br /> over from an earlier prototype of the PCL work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi: Do not import certificates from UEFI Secure Boot for T2 Macs<br /> <br /> On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables<br /> at early boot to load UEFI Secure Boot certificates, a page fault occurs<br /> in Apple firmware code and EFI runtime services are disabled with the<br /> following logs:<br /> <br /> [Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000<br /> WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0<br /> (Removed some logs from here)<br /> Call Trace:<br /> <br /> page_fault_oops+0x4f/0x2c0<br /> ? search_bpf_extables+0x6b/0x80<br /> ? search_module_extables+0x50/0x80<br /> ? search_exception_tables+0x5b/0x60<br /> kernelmode_fixup_or_oops+0x9e/0x110<br /> __bad_area_nosemaphore+0x155/0x190<br /> bad_area_nosemaphore+0x16/0x20<br /> do_kern_addr_fault+0x8c/0xa0<br /> exc_page_fault+0xd8/0x180<br /> asm_exc_page_fault+0x1e/0x30<br /> (Removed some logs from here)<br /> ? __efi_call+0x28/0x30<br /> ? switch_mm+0x20/0x30<br /> ? efi_call_rts+0x19a/0x8e0<br /> ? process_one_work+0x222/0x3f0<br /> ? worker_thread+0x4a/0x3d0<br /> ? kthread+0x17a/0x1a0<br /> ? process_one_work+0x3f0/0x3f0<br /> ? set_kthread_struct+0x40/0x40<br /> ? ret_from_fork+0x22/0x30<br /> <br /> ---[ end trace 1f82023595a5927f ]---<br /> efi: Froze efi_rts_wq and disabled EFI Runtime Services<br /> integrity: Couldn&amp;#39;t get size: 0x8000000000000015<br /> integrity: MODSIGN: Couldn&amp;#39;t get UEFI db list<br /> efi: EFI Runtime Services are disabled!<br /> integrity: Couldn&amp;#39;t get size: 0x8000000000000015<br /> integrity: Couldn&amp;#39;t get UEFI dbx list<br /> integrity: Couldn&amp;#39;t get size: 0x8000000000000015<br /> integrity: Couldn&amp;#39;t get mokx list<br /> integrity: Couldn&amp;#39;t get size: 0x80000000<br /> <br /> So we avoid reading these UEFI variables and thus prevent the crash.

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)