Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: fbtft: core: set smem_len before fb_deferred_io_init call<br /> <br /> The fbtft_framebuffer_alloc() calls fb_deferred_io_init() before<br /> initializing info-&gt;fix.smem_len. It is set to zero by the<br /> framebuffer_alloc() function. It will trigger a WARN_ON() at the<br /> start of fb_deferred_io_init() and the function will not do anything.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/srpt: Fix a use-after-free<br /> <br /> Change the LIO port members inside struct srpt_port from regular members<br /> into pointers. Allocate the LIO port data structures from inside<br /> srpt_make_tport() and free these from inside srpt_make_tport(). Keep<br /> struct srpt_device as long as either an RDMA port or a LIO target port is<br /> associated with it. This patch decouples the lifetime of struct srpt_port<br /> (controlled by the RDMA core) and struct srpt_port_id (controlled by LIO).<br /> This patch fixes the following KASAN complaint:<br /> <br /> BUG: KASAN: use-after-free in srpt_enable_tpg+0x31/0x70 [ib_srpt]<br /> Read of size 8 at addr ffff888141cc34b8 by task check/5093<br /> <br /> Call Trace:<br /> <br /> show_stack+0x4e/0x53<br /> dump_stack_lvl+0x51/0x66<br /> print_address_description.constprop.0.cold+0xea/0x41e<br /> print_report.cold+0x90/0x205<br /> kasan_report+0xb9/0xf0<br /> __asan_load8+0x69/0x90<br /> srpt_enable_tpg+0x31/0x70 [ib_srpt]<br /> target_fabric_tpg_base_enable_store+0xe2/0x140 [target_core_mod]<br /> configfs_write_iter+0x18b/0x210<br /> new_sync_write+0x1f2/0x2f0<br /> vfs_write+0x3e3/0x540<br /> ksys_write+0xbb/0x140<br /> __x64_sys_write+0x42/0x50<br /> do_syscall_64+0x34/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix error unwind in rxe_create_qp()<br /> <br /> In the function rxe_create_qp(), rxe_qp_from_init() is called to<br /> initialize qp, internally things like the spin locks are not setup until<br /> rxe_qp_init_req().<br /> <br /> If an error occures before this point then the unwind will call<br /> rxe_cleanup() and eventually to rxe_qp_do_cleanup()/rxe_cleanup_task()<br /> which will oops when trying to access the uninitialized spinlock.<br /> <br /> Move the spinlock initializations earlier before any failures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jbd2: fix assertion &amp;#39;jh-&gt;b_frozen_data == NULL&amp;#39; failure when journal aborted<br /> <br /> Following process will fail assertion &amp;#39;jh-&gt;b_frozen_data == NULL&amp;#39; in<br /> jbd2_journal_dirty_metadata():<br /> <br /> jbd2_journal_commit_transaction<br /> unlink(dir/a)<br /> jh-&gt;b_transaction = trans1<br /> jh-&gt;b_jlist = BJ_Metadata<br /> journal-&gt;j_running_transaction = NULL<br /> trans1-&gt;t_state = T_COMMIT<br /> unlink(dir/b)<br /> handle-&gt;h_trans = trans2<br /> do_get_write_access<br /> jh-&gt;b_modified = 0<br /> jh-&gt;b_frozen_data = frozen_buffer<br /> jh-&gt;b_next_transaction = trans2<br /> jbd2_journal_dirty_metadata<br /> is_handle_aborted<br /> is_journal_aborted // return false<br /> <br /> --&gt; jbd2 abort t_buffers)<br /> if (is_journal_aborted)<br /> jbd2_journal_refile_buffer<br /> __jbd2_journal_refile_buffer<br /> WRITE_ONCE(jh-&gt;b_transaction,<br /> jh-&gt;b_next_transaction)<br /> WRITE_ONCE(jh-&gt;b_next_transaction, NULL)<br /> __jbd2_journal_file_buffer(jh, BJ_Reserved)<br /> J_ASSERT_JH(jh, jh-&gt;b_frozen_data == NULL) // assertion failure !<br /> <br /> The reproducer (See detail in [Link]) reports:<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/jbd2/transaction.c:1629!<br /> invalid opcode: 0000 [#1] PREEMPT SMP<br /> CPU: 2 PID: 584 Comm: unlink Tainted: G W<br /> 5.19.0-rc6-00115-g4a57a8400075-dirty #697<br /> RIP: 0010:jbd2_journal_dirty_metadata+0x3c5/0x470<br /> RSP: 0018:ffffc90000be7ce0 EFLAGS: 00010202<br /> Call Trace:<br /> <br /> __ext4_handle_dirty_metadata+0xa0/0x290<br /> ext4_handle_dirty_dirblock+0x10c/0x1d0<br /> ext4_delete_entry+0x104/0x200<br /> __ext4_unlink+0x22b/0x360<br /> ext4_unlink+0x275/0x390<br /> vfs_unlink+0x20b/0x4c0<br /> do_unlinkat+0x42f/0x4c0<br /> __x64_sys_unlink+0x37/0x50<br /> do_syscall_64+0x35/0x80<br /> <br /> After journal aborting, __jbd2_journal_refile_buffer() is executed with<br /> holding @jh-&gt;b_state_lock, we can fix it by moving &amp;#39;is_handle_aborted()&amp;#39;<br /> into the area protected by @jh-&gt;b_state_lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: cros_ec_codec: Fix refcount leak in cros_ec_codec_platform_probe<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mt6797-mt6351: Fix refcount leak in mt6797_mt6351_dev_probe<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8173: Fix refcount leak in mt8173_rt5650_rt5676_dev_probe<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Fix missing of_node_put() in error paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8173-rt5650: Fix refcount leak in mt8173_rt5650_dev_probe<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Fix refcount leak in some error paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init<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 child node.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: imx_rproc: Fix refcount leak in imx_rproc_addr_init<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not needed anymore.<br /> This function has two paths missing of_node_put().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpmsg: Fix possible refcount leak in rpmsg_register_device_override()<br /> <br /> rpmsg_register_device_override need to call put_device to free vch when<br /> driver_set_override fails.<br /> <br /> Fix this by adding a put_device() to the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable<br /> <br /> commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear<br /> pending PMI before resetting an overflown PMC") added a new<br /> function "pmi_irq_pending" in hw_irq.h. This function is to check<br /> if there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is<br /> used in power_pmu_disable in a WARN_ON. The intention here is to<br /> provide a warning if there is PMI pending, but no counter is found<br /> overflown.<br /> <br /> During some of the perf runs, below warning is hit:<br /> <br /> WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0<br /> Modules linked in:<br /> -----<br /> <br /> NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0<br /> LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0<br /> Call Trace:<br /> [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable)<br /> [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60<br /> [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100<br /> [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240<br /> [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140<br /> [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0<br /> [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300<br /> [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100<br /> [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40<br /> [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250<br /> [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0<br /> [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0<br /> [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80<br /> [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0<br /> [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140<br /> [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8<br /> [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0<br /> [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220<br /> <br /> This means that there is no PMC overflown among the active events<br /> in the PMU, but there is a PMU pending in Paca. The function<br /> "any_pmc_overflown" checks the PMCs on active events in<br /> cpuhw-&gt;n_events. Code snippet:<br /> <br /> <br /> if (any_pmc_overflown(cpuhw))<br /> clear_pmi_irq_pending();<br /> else<br /> WARN_ON(pmi_irq_pending());<br /> <br /> <br /> Here the PMC overflown is not from active event. Example: When we do<br /> perf record, default cycles and instructions will be running on PMC6<br /> and PMC5 respectively. It could happen that overflowed event is currently<br /> not active and pending PMI is for the inactive event. Debug logs from<br /> trace_printk:<br /> <br /> <br /> any_pmc_overflown: idx is 5: pmc value is 0xd9a<br /> power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011<br /> <br /> <br /> Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011).<br /> When we handle PMI interrupt for such cases, if the PMC overflown is<br /> from inactive event, it will be ignored. Reference commit:<br /> commit bc09c219b2e6 ("powerpc/perf: Fix finding overflowed PMC in interrupt")<br /> <br /> Patch addresses two changes:<br /> 1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); )<br /> We were printing warning if no PMC is found overflown among active PMU<br /> events, but PMI pending in PACA. But this could happen in cases where<br /> PMC overflown is not in active PMC. An inactive event could have caused<br /> the overflow. Hence the warning is not needed. To know pending PMI is<br /> from an inactive event, we need to loop through all PMC&amp;#39;s which will<br /> cause more SPR reads via mfspr and increase in context switch. Also in<br /> existing function: perf_event_interrupt, already we ignore PMI&amp;#39;s<br /> overflown when it is from an inactive PMC.<br /> <br /> 2) Fix 2: optimization in clearing pending PMI.<br /> Currently we check for any active PMC overflown before clearing PMI<br /> pending in Paca. This is causing additional SP<br /> ---truncated---