Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio: Split migration ops from main device ops<br /> <br /> vfio core checks whether the driver sets some migration op (e.g.<br /> set_state/get_state) and accordingly calls its op.<br /> <br /> However, currently mlx5 driver sets the above ops without regards to its<br /> migration caps.<br /> <br /> This might lead to unexpected usage/Oops if user space may call to the<br /> above ops even if the driver doesn&amp;#39;t support migration. As for example,<br /> the migration state_mutex is not initialized in that case.<br /> <br /> The cleanest way to manage that seems to split the migration ops from<br /> the main device ops, this will let the driver setting them separately<br /> from the main ops when it&amp;#39;s applicable.<br /> <br /> As part of that, validate ops construction on registration and include a<br /> check for VFIO_MIGRATION_STOP_COPY since the uAPI claims it must be set<br /> in migration_flags.<br /> <br /> HISI driver was changed as well to match this scheme.<br /> <br /> This scheme may enable down the road to come with some extra group of<br /> ops (e.g. DMA log) that can be set without regards to the other options<br /> based on driver caps.

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

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 /> 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 /> 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 /> 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 /> powerpc/cell/axon_msi: Fix refcount leak in setup_msi_msg_address<br /> <br /> of_get_next_parent() returns a node pointer with refcount incremented,<br /> we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() in the error path to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix memory leak when using fscache<br /> <br /> If we hit the &amp;#39;index == next_cached&amp;#39; case, we leak a refcount on the<br /> struct page. Fix this by using readahead_folio() which takes care of<br /> the refcount for you.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: max77620: Fix refcount leak in max77620_initialise_fps<br /> <br /> of_get_child_by_name() 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 /> video: fbdev: amba-clcd: Fix refcount leak bugs<br /> <br /> In clcdfb_of_init_display(), we should call of_node_put() for the<br /> references returned by of_graph_get_next_endpoint() and<br /> of_graph_get_remote_port_parent() which have increased the refcount.<br /> <br /> Besides, we should call of_node_put() both in fail path or when<br /> the references are not used anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: sp5100_tco: Fix a memory leak of EFCH MMIO resource<br /> <br /> Unlike release_mem_region(), a call to release_resource() does not<br /> free the resource, so it has to be freed explicitly to avoid a memory<br /> leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mt6359: Fix refcount leak bug<br /> <br /> In mt6359_parse_dt() and mt6359_accdet_parse_dt(), we should call<br /> of_node_put() for the reference returned by of_get_child_by_name()<br /> which has increased the refcount.