Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: ts4800_wdt: Fix refcount leak in ts4800_wdt_probe<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() in some error paths.

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 /> 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 /> powerpc/papr_scm: don&amp;#39;t requests stats with &amp;#39;0&amp;#39; sized stats buffer<br /> <br /> Sachin reported [1] that on a POWER-10 lpar he is seeing a kernel panic being<br /> reported with vPMEM when papr_scm probe is being called. The panic is of the<br /> form below and is observed only with following option disabled(profile) for the<br /> said LPAR &amp;#39;Enable Performance Information Collection&amp;#39; in the HMC:<br /> <br /> Kernel attempted to write user page (1c) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on write at 0x0000001c<br /> Faulting instruction address: 0xc008000001b90844<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> <br /> NIP [c008000001b90844] drc_pmem_query_stats+0x5c/0x270 [papr_scm]<br /> LR [c008000001b92794] papr_scm_probe+0x2ac/0x6ec [papr_scm]<br /> Call Trace:<br /> 0xc00000000941bca0 (unreliable)<br /> papr_scm_probe+0x2ac/0x6ec [papr_scm]<br /> platform_probe+0x98/0x150<br /> really_probe+0xfc/0x510<br /> __driver_probe_device+0x17c/0x230<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> On investigation looks like this panic was caused due to a &amp;#39;stat_buffer&amp;#39; of<br /> size==0 being provided to drc_pmem_query_stats() to fetch all performance<br /> stats-ids of an NVDIMM. However drc_pmem_query_stats() shouldn&amp;#39;t have been called<br /> since the vPMEM NVDIMM doesn&amp;#39;t support and performance stat-id&amp;#39;s. This was caused<br /> due to missing check for &amp;#39;p-&gt;stat_buffer_len&amp;#39; at the beginning of<br /> papr_scm_pmu_check_events() which indicates that the NVDIMM doesn&amp;#39;t support<br /> performance-stats.<br /> <br /> Fix this by introducing the check for &amp;#39;p-&gt;stat_buffer_len&amp;#39; at the beginning of<br /> papr_scm_pmu_check_events().<br /> <br /> [1] https://lore.kernel.org/all/6B3A522A-6A5F-4CC9-B268-0C63AA6E07D3@linux.ibm.com

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.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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 /> 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 /> 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.