Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix bug_on in __es_tree_search caused by bad boot loader inode<br /> <br /> We got a issue as fllows:<br /> ==================================================================<br /> kernel BUG at fs/ext4/extents_status.c:203!<br /> invalid opcode: 0000 [#1] PREEMPT SMP<br /> CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty #349<br /> RIP: 0010:ext4_es_end.isra.0+0x34/0x42<br /> RSP: 0018:ffffc9000143b768 EFLAGS: 00010203<br /> RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff<br /> RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8<br /> R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0<br /> R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000<br /> FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __es_tree_search.isra.0+0x6d/0xf5<br /> ext4_es_cache_extent+0xfa/0x230<br /> ext4_cache_extents+0xd2/0x110<br /> ext4_find_extent+0x5d5/0x8c0<br /> ext4_ext_map_blocks+0x9c/0x1d30<br /> ext4_map_blocks+0x431/0xa50<br /> ext4_mpage_readpages+0x48e/0xe40<br /> ext4_readahead+0x47/0x50<br /> read_pages+0x82/0x530<br /> page_cache_ra_unbounded+0x199/0x2a0<br /> do_page_cache_ra+0x47/0x70<br /> page_cache_ra_order+0x242/0x400<br /> ondemand_readahead+0x1e8/0x4b0<br /> page_cache_sync_ra+0xf4/0x110<br /> filemap_get_pages+0x131/0xb20<br /> filemap_read+0xda/0x4b0<br /> generic_file_read_iter+0x13a/0x250<br /> ext4_file_read_iter+0x59/0x1d0<br /> vfs_read+0x28f/0x460<br /> ksys_read+0x73/0x160<br /> __x64_sys_read+0x1e/0x30<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> ==================================================================<br /> <br /> In the above issue, ioctl invokes the swap_inode_boot_loader function to<br /> swap inode and inode. However, inode contain incorrect imode and<br /> disordered extents, and i_nlink is set to 1. The extents check for inode in<br /> the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO.<br /> While links_count is set to 1, the extents are not initialized in<br /> swap_inode_boot_loader. After the ioctl command is executed successfully,<br /> the extents are swapped to inode, in this case, run the `cat` command<br /> to view inode. And Bug_ON is triggered due to the incorrect extents.<br /> <br /> When the boot loader inode is not initialized, its imode can be one of the<br /> following:<br /> 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and<br /> set to S_IFREG.<br /> 2) the imode is good type but not S_IFREG.<br /> 3) the imode is S_IFREG.<br /> <br /> The BUG_ON may be triggered by bypassing the check in cases 1 and 2.<br /> Therefore, when the boot loader inode is bad_inode or its imode is not<br /> S_IFREG, initialize the inode to avoid triggering the BUG.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io-wq: Fix memory leak in worker creation<br /> <br /> If the CPU mask allocation for a node fails, then the memory allocated for<br /> the &amp;#39;io_wqe&amp;#39; struct of the current node doesn&amp;#39;t get freed on the error<br /> handling path, since it has not yet been added to the &amp;#39;wqes&amp;#39; array.<br /> <br /> This was spotted when fuzzing v6.1-rc1 with Syzkaller:<br /> BUG: memory leak<br /> unreferenced object 0xffff8880093d5000 (size 1024):<br /> comm "syz-executor.2", pid 7701, jiffies 4295048595 (age 13.900s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x18e/0x720<br /> [] kmalloc_node_trace+0x2a/0x130<br /> [] io_wq_create+0x7b9/0xdc0<br /> [] io_uring_alloc_task_context+0x31e/0x59d<br /> [] __io_uring_add_tctx_node.cold+0x19/0x1ba<br /> [] io_uring_setup.cold+0x1b80/0x1dce<br /> [] __x64_sys_io_uring_setup+0x5d/0x80<br /> [] do_syscall_64+0x5d/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: core: Fix kernel panic when remove non-standard SDIO card<br /> <br /> SDIO tuple is only allocated for standard SDIO card, especially it causes<br /> memory corruption issues when the non-standard SDIO card has removed, which<br /> is because the card device&amp;#39;s reference counter does not increase for it at<br /> sdio_init_func(), but all SDIO card device reference counter gets decreased<br /> at sdio_release_func().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HSI: omap_ssi: Fix refcount leak in ssi_probe<br /> <br /> When returning or breaking early from a<br /> for_each_available_child_of_node() loop, we need to explicitly call<br /> of_node_put() on the child node to possibly release the node.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/chrome: cros_ec_typec: zero out stale pointers<br /> <br /> `cros_typec_get_switch_handles` allocates four pointers when obtaining<br /> type-c switch handles. These pointers are all freed if failing to obtain<br /> any of them; therefore, pointers in `port` become stale. The stale<br /> pointers eventually cause use-after-free or double free in later code<br /> paths. Zeroing out all pointer fields after freeing to eliminate these<br /> stale pointers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix xid leak in cifs_copy_file_range()<br /> <br /> If the file is used by swap, before return -EOPNOTSUPP, should<br /> free the xid, otherwise, the xid will be leaked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: ti: dra7-atl: Fix reference leak in of_dra7_atl_clk_probe<br /> <br /> pm_runtime_get_sync() will increment pm usage counter.<br /> Forgetting to putting operation will result in reference leak.<br /> Add missing pm_runtime_put_sync in some error paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: perf: marvell_cn10k: Fix hotplug callback leak in tad_pmu_init()<br /> <br /> tad_pmu_init() won&amp;#39;t remove the callback added by cpuhp_setup_state_multi()<br /> when platform_driver_register() failed. Remove the callback by<br /> cpuhp_remove_multi_state() in fail path.<br /> <br /> Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:<br /> arm-ccn: Prevent hotplug callback leak")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: qcom: Fix memory leak in dwc3_qcom_interconnect_init<br /> <br /> of_icc_get() alloc resources for path handle, we should release it when not<br /> need anymore. Like the release in dwc3_qcom_interconnect_exit() function.<br /> Add icc_put() in error handling to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: cw2015: Fix potential null-ptr-deref in cw_bat_probe()<br /> <br /> cw_bat_probe() calls create_singlethread_workqueue() and not checked the<br /> ret value, which may return NULL. And a null-ptr-deref may happen:<br /> <br /> cw_bat_probe()<br /> create_singlethread_workqueue() # failed, cw_bat-&gt;wq is NULL<br /> queue_delayed_work()<br /> queue_delayed_work_on()<br /> __queue_delayed_work() # warning here, but continue<br /> __queue_work() # access wq-&gt;flags, null-ptr-deref<br /> <br /> Check the ret value and return -ENOMEM if it is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/kprobes: Fix null pointer reference in arch_prepare_kprobe()<br /> <br /> I found a null pointer reference in arch_prepare_kprobe():<br /> <br /> # echo &amp;#39;p cmdline_proc_show&amp;#39; &gt; kprobe_events<br /> # echo &amp;#39;p cmdline_proc_show+16&amp;#39; &gt;&gt; kprobe_events<br /> Kernel attempted to read user page (0) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000000<br /> Faulting instruction address: 0xc000000000050bfc<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV<br /> Modules linked in:<br /> CPU: 0 PID: 122 Comm: sh Not tainted 6.0.0-rc3-00007-gdcf8e5633e2e #10<br /> NIP: c000000000050bfc LR: c000000000050bec CTR: 0000000000005bdc<br /> REGS: c0000000348475b0 TRAP: 0300 Not tainted (6.0.0-rc3-00007-gdcf8e5633e2e)<br /> MSR: 9000000000009033 CR: 88002444 XER: 20040006<br /> CFAR: c00000000022d100 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0<br /> ...<br /> NIP arch_prepare_kprobe+0x10c/0x2d0<br /> LR arch_prepare_kprobe+0xfc/0x2d0<br /> Call Trace:<br /> 0xc0000000012f77a0 (unreliable)<br /> register_kprobe+0x3c0/0x7a0<br /> __register_trace_kprobe+0x140/0x1a0<br /> __trace_kprobe_create+0x794/0x1040<br /> trace_probe_create+0xc4/0xe0<br /> create_or_delete_trace_kprobe+0x2c/0x80<br /> trace_parse_run_command+0xf0/0x210<br /> probes_write+0x20/0x40<br /> vfs_write+0xfc/0x450<br /> ksys_write+0x84/0x140<br /> system_call_exception+0x17c/0x3a0<br /> system_call_vectored_common+0xe8/0x278<br /> --- interrupt: 3000 at 0x7fffa5682de0<br /> NIP: 00007fffa5682de0 LR: 0000000000000000 CTR: 0000000000000000<br /> REGS: c000000034847e80 TRAP: 3000 Not tainted (6.0.0-rc3-00007-gdcf8e5633e2e)<br /> MSR: 900000000280f033 CR: 44002408 XER: 00000000<br /> <br /> The address being probed has some special:<br /> <br /> cmdline_proc_show: Probe based on ftrace<br /> cmdline_proc_show+16: Probe for the next instruction at the ftrace location<br /> <br /> The ftrace-based kprobe does not generate kprobe::ainsn::insn, it gets<br /> set to NULL. In arch_prepare_kprobe() it will check for:<br /> <br /> ...<br /> prev = get_kprobe(p-&gt;addr - 1);<br /> preempt_enable_no_resched();<br /> if (prev &amp;&amp; ppc_inst_prefixed(ppc_inst_read(prev-&gt;ainsn.insn))) {<br /> ...<br /> <br /> If prev is based on ftrace, &amp;#39;ppc_inst_read(prev-&gt;ainsn.insn)&amp;#39; will occur<br /> with a null pointer reference. At this point prev-&gt;addr will not be a<br /> prefixed instruction, so the check can be skipped.<br /> <br /> Check if prev is ftrace-based kprobe before reading &amp;#39;prev-&gt;ainsn.insn&amp;#39;<br /> to fix this problem.<br /> <br /> [mpe: Trim oops]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix pci_device_is_present() for VFs by checking PF<br /> <br /> pci_device_is_present() previously didn&amp;#39;t work for VFs because it reads the<br /> Vendor and Device ID, which are 0xffff for VFs, which looks like they<br /> aren&amp;#39;t present. Check the PF instead.<br /> <br /> Wei Gong reported that if virtio I/O is in progress when the driver is<br /> unbound or "0" is written to /sys/.../sriov_numvfs, the virtio I/O<br /> operation hangs, which may result in output like this:<br /> <br /> task:bash state:D stack: 0 pid: 1773 ppid: 1241 flags:0x00004002<br /> Call Trace:<br /> schedule+0x4f/0xc0<br /> blk_mq_freeze_queue_wait+0x69/0xa0<br /> blk_mq_freeze_queue+0x1b/0x20<br /> blk_cleanup_queue+0x3d/0xd0<br /> virtblk_remove+0x3c/0xb0 [virtio_blk]<br /> virtio_dev_remove+0x4b/0x80<br /> ...<br /> device_unregister+0x1b/0x60<br /> unregister_virtio_device+0x18/0x30<br /> virtio_pci_remove+0x41/0x80<br /> pci_device_remove+0x3e/0xb0<br /> <br /> This happened because pci_device_is_present(VF) returned "false" in<br /> virtio_pci_remove(), so it called virtio_break_device(). The broken vq<br /> meant that vring_interrupt() skipped the vq.callback() that would have<br /> completed the virtio I/O operation via virtblk_done().<br /> <br /> [bhelgaas: commit log, simplify to always use pci_physfn(), add stable tag]