Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: 9p: fix refcount leak in p9_read_work() error handling<br /> <br /> p9_req_put need to be called when m-&gt;rreq-&gt;rc.sdata is NULL to avoid<br /> temporary refcount leak.<br /> <br /> [Dominique: commit wording adjustments, p9_req_put argument fixes for rebase]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: ipc3-topology: Prevent double freeing of ipc_control_data via load_bytes<br /> <br /> We have sanity checks for byte controls and if any of the fail the locally<br /> allocated scontrol-&gt;ipc_control_data is freed up, but not set to NULL.<br /> <br /> On a rollback path of the error the higher level code will also try to free<br /> the scontrol-&gt;ipc_control_data which will eventually going to lead to<br /> memory corruption as double freeing memory is not a good thing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: n_gsm: fix deadlock and link starvation in outgoing data path<br /> <br /> The current implementation queues up new control and user packets as needed<br /> and processes this queue down to the ldisc in the same code path.<br /> That means that the upper and the lower layer are hard coupled in the code.<br /> Due to this deadlocks can happen as seen below while transmitting data,<br /> especially during ldisc congestion. Furthermore, the data channels starve<br /> the control channel on high transmission load on the ldisc.<br /> <br /> Introduce an additional control channel data queue to prevent timeouts and<br /> link hangups during ldisc congestion. This is being processed before the<br /> user channel data queue in gsm_data_kick(), i.e. with the highest priority.<br /> Put the queue to ldisc data path into a workqueue and trigger it whenever<br /> new data has been put into the transmission queue. Change<br /> gsm_dlci_data_sweep() accordingly to fill up the transmission queue until<br /> TX_THRESH_HI. This solves the locking issue, keeps latency low and provides<br /> good performance on high data load.<br /> Note that now all packets from a DLCI are removed from the internal queue<br /> if the associated DLCI was closed. This ensures that no data is sent by the<br /> introduced write task to an already closed DLCI.<br /> <br /> BUG: spinlock recursion on CPU#0, test_v24_loop/124<br /> lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0<br /> CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x34/0x44<br /> do_raw_spin_lock+0x76/0xa0<br /> _raw_spin_lock_irqsave+0x72/0x80<br /> uart_write_room+0x3b/0xc0<br /> gsm_data_kick+0x14b/0x240 [n_gsm]<br /> gsmld_write_wakeup+0x35/0x70 [n_gsm]<br /> tty_wakeup+0x53/0x60<br /> tty_port_default_wakeup+0x1b/0x30<br /> serial8250_tx_chars+0x12f/0x220<br /> serial8250_handle_irq.part.0+0xfe/0x150<br /> serial8250_default_handle_irq+0x48/0x80<br /> serial8250_interrupt+0x56/0xa0<br /> __handle_irq_event_percpu+0x78/0x1f0<br /> handle_irq_event+0x34/0x70<br /> handle_fasteoi_irq+0x90/0x1e0<br /> __common_interrupt+0x69/0x100<br /> common_interrupt+0x48/0xc0<br /> asm_common_interrupt+0x1e/0x40<br /> RIP: 0010:__do_softirq+0x83/0x34e<br /> Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d<br /> e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff c7 c2 40 61<br /> 80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00<br /> RSP: 0018:ffffc90000003f98 EFLAGS: 00000286<br /> RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7<br /> RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000<br /> R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000<br /> ? __do_softirq+0x73/0x34e<br /> irq_exit_rcu+0xb5/0x100<br /> common_interrupt+0xa4/0xc0<br /> <br /> <br /> asm_common_interrupt+0x1e/0x40<br /> RIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50<br /> Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff<br /> 48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 3d 97 33 ff<br /> 65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44<br /> RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202<br /> RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000<br /> RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001<br /> RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000<br /> R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8<br /> ? _raw_spin_unlock_irqrestore+0x23/0x50<br /> gsmtty_write+0x65/0x80 [n_gsm]<br /> n_tty_write+0x33f/0x530<br /> ? swake_up_all+0xe0/0xe0<br /> file_tty_write.constprop.0+0x1b1/0x320<br /> ? n_tty_flush_buffer+0xb0/0xb0<br /> new_sync_write+0x10c/0x190<br /> vfs_write+0x282/0x310<br /> ksys_write+0x68/0xe0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f3e5e35c15c<br /> Code: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24<br /> ---truncated---

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.