Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-50108 State: PUBLISHED Published: 2025-06-18T11:02:42.037Z Last Updated: 2025-06-18T11:02:42.037Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mfd: max77620: Fix refcount leak in max77620_initialise_fps of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. References: - https://git.kernel.org/stable/c/b948ff8a9e9ad46d4dff9127777caa14c8c2b53c - https://git.kernel.org/stable/c/afdbadbf18c19779d7bc5df70d872924f9bbd76b - https://git.kernel.org/stable/c/facd31bbc799f4d0cd25d9d688af7ca41e7f3
table/c/afdbadbf18c19779d7bc5df70d872924f9bbd76b - https://git.kernel.org/stable/c/facd31bbc799f4d0cd25d9d688af7ca41e7f38ee - https://git.kernel.org/stable/c/50d5fe8cb94c319cb4316f4d824570c075565354 - https://git.kernel.org/stable/c/a29c40814039535b950149311986a5f348b5db14 - https://git.kernel.org/stable/c/1520669c8255bd637c6b248b2be910e2688d38dd
CVE ID: CVE-2022-50109 State: PUBLISHED Published: 2025-06-18T11:02:42.667Z Last Updated: 2025-06-18T11:02:42.667Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: video: fbdev: amba-clcd: Fix refcount leak bugs In clcdfb_of_init_display(), we should call of_node_put() for the references returned by of_graph_get_next_endpoint() and of_graph_get_remote_port_parent() which have increased the refcount. Besides, we should call of_node_put() both in fail path or when the references are not used anymore. References: - https://git.kernel.org/stable/c/2688df86c02da6bdc9866b62d974e169a2678883 - https://git.kernel.org/stable/c/a97ff8a949db
https://git.kernel.org/stable/c/2688df86c02da6bdc9866b62d974e169a2678883 - https://git.kernel.org/stable/c/a97ff8a949dbf41be89f436b2b1a2b3d794493df - https://git.kernel.org/stable/c/49a4c1a87ef884e43cdda58b142a2a30f2f09efc - https://git.kernel.org/stable/c/da276dc288bf838ea0fd778b5441ec0f601c69f7 - https://git.kernel.org/stable/c/29f06f1905c312671a09ee85ca92ac04a1d9f305 - https://git.kernel.org/stable/c/a51519ebd0fdad3546463018b8f6bc3b0f4d3032 - https://git.kernel.org/stable/c/a88ab277cca99aeb9a3b2b7db358f1a6dd528b0c - https://git.kernel.org/stable/c/26c2b7d9fac42eb8317f3ceefa4c1a9a9170ca69
CVE ID: CVE-2022-50110 State: PUBLISHED Published: 2025-06-18T11:02:43.370Z Last Updated: 2025-06-18T11:02:43.370Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: watchdog: sp5100_tco: Fix a memory leak of EFCH MMIO resource Unlike release_mem_region(), a call to release_resource() does not free the resource, so it has to be freed explicitly to avoid a memory leak. References: - https://git.kernel.org/stable/c/84ddf527f90755beec6b55ce2e31331f5ccd4e37 - https://git.kernel.org/stable/c/3a1becb1f13268ef58f19190608a7c742fb6fcf5 - https://git.kernel.org/stable/c/ee1fb8f75abe361413913e3a6e93c8c0a4d83cd9 - https://git.kernel.org/stable
a7c742fb6fcf5 - https://git.kernel.org/stable/c/ee1fb8f75abe361413913e3a6e93c8c0a4d83cd9 - https://git.kernel.org/stable/c/c6d9c0798ed366a09a9e53d71edcd2266e34a6eb
CVE ID: CVE-2022-50111 State: PUBLISHED Published: 2025-06-18T11:02:44.006Z Last Updated: 2025-06-18T11:02:44.006Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: mt6359: Fix refcount leak bug In mt6359_parse_dt() and mt6359_accdet_parse_dt(), we should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount. References: - https://git.kernel.org/stable/c/3d69d86b3e9d82f524e7e1906adcbbe939dc836e - https://git.kernel.org/stable/c/ffaef892bfef5ec68dadfd3bbed49e3d4ef7b6c7 - https://git.kernel.org/stable/c/1e7fe6906e9755d9e0242f9619c894ecd82fb9da - https://git.kernel.org/stable/c
e3d4ef7b6c7 - https://git.kernel.org/stable/c/1e7fe6906e9755d9e0242f9619c894ecd82fb9da - https://git.kernel.org/stable/c/a8d5df69e2ec702d979f7d04ed519caf8691a032
CVE ID: CVE-2022-50112 State: PUBLISHED Published: 2025-06-18T11:02:44.805Z Last Updated: 2025-06-18T11:02:44.805Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rpmsg: qcom_smd: Fix refcount leak in qcom_smd_parse_edge of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. References: - https://git.kernel.org/stable/c/cb50423e46ea585620a6be307d7f7b71587936b7 - https://git.kernel.org/stable/c/8ee5d40ae29e63f6fd6cbf9dcfc0a48c474013db - https://git.kernel.org/stable/c/9715809b9eeb85b3f9b083857a2f29a9e2351125 - https://git.kernel.org/stable/c/ece6cfe62a103cc6032664983be557
l.org/stable/c/9715809b9eeb85b3f9b083857a2f29a9e2351125 - https://git.kernel.org/stable/c/ece6cfe62a103cc6032664983be557f1b5a1ff7e - https://git.kernel.org/stable/c/ae7fdbab97df6a2115eed6b7e39c278b805c9c7d - https://git.kernel.org/stable/c/43e42c25a232a6862e7d2f292a069ac828559030 - https://git.kernel.org/stable/c/65382585f067d4256ba087934f30f85c9b6984de
CVE ID: CVE-2022-50113 State: PUBLISHED Published: 2025-06-18T11:02:45.475Z Last Updated: 2025-06-18T11:02:45.475Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoc: audio-graph-card2: Fix refcount leak bug in __graph_get_type() We should call of_node_put() for the reference before its replacement as it returned by of_get_parent() which has increased the refcount. Besides, we should also call of_node_put() before return. References: - https://git.kernel.org/stable/c/3bb0c0b5f0f866fc3785380e0860dc37ceacf342 - https://git.kernel.org/stable/c/7a63a8c253bf57dfd9fa3ee2a7f1a3727505f947 - https://git.kernel.org/stable/c/eda26893dabf
https://git.kernel.org/stable/c/7a63a8c253bf57dfd9fa3ee2a7f1a3727505f947 - https://git.kernel.org/stable/c/eda26893dabfc6da7a1e1ff5f8628ed9faab3ab9
CVE ID: CVE-2022-50114 State: PUBLISHED Published: 2025-06-18T11:02:46.152Z Last Updated: 2025-06-18T11:02:46.152Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: 9p: fix refcount leak in p9_read_work() error handling p9_req_put need to be called when m->rreq->rc.sdata is NULL to avoid temporary refcount leak. [Dominique: commit wording adjustments, p9_req_put argument fixes for rebase] References: - https://git.kernel.org/stable/c/8324649b0035cbb30ebc3ca901540cb392e89041 - https://git.kernel.org/stable/c/622f2a467bdfbce73fd43ea74b5f0fd2caaa8c5d - https://git.kernel.org/stable/c/34b9a188557c1d5a50e07cf228d054101aee0af3 - ht
622f2a467bdfbce73fd43ea74b5f0fd2caaa8c5d - https://git.kernel.org/stable/c/34b9a188557c1d5a50e07cf228d054101aee0af3 - https://git.kernel.org/stable/c/4ac7573e1f9333073fa8d303acc941c9b7ab7f61
CVE ID: CVE-2022-50115 State: PUBLISHED Published: 2025-06-18T11:02:46.759Z Last Updated: 2025-06-18T11:02:46.759Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc3-topology: Prevent double freeing of ipc_control_data via load_bytes We have sanity checks for byte controls and if any of the fail the locally allocated scontrol->ipc_control_data is freed up, but not set to NULL. On a rollback path of the error the higher level code will also try to free the scontrol->ipc_control_data which will eventually going to lead to memory corruption as double freeing memory is not a good thing. References: - https://git.kernel.
ually going to lead to memory corruption as double freeing memory is not a good thing. References: - https://git.kernel.org/stable/c/8463986b54295e6b65ddf2b7c65627d01ce7643b - https://git.kernel.org/stable/c/c2eddfcafcffaf1b9245ea0dde9143bbfb47d5d1 - https://git.kernel.org/stable/c/d5bd47f3ca124058a8e87eae4508afeda2132611
CVE ID: CVE-2022-50116 State: PUBLISHED Published: 2025-06-18T11:02:47.361Z Last Updated: 2025-06-18T11:02:47.361Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix deadlock and link starvation in outgoing data path The current implementation queues up new control and user packets as needed and processes this queue down to the ldisc in the same code path. That means that the upper and the lower layer are hard coupled in the code. Due to this deadlocks can happen as seen below while transmitting data, especially during ldisc congestion. Furthermore, the data channels starve the control channel on high transmission l
ta, especially during ldisc congestion. Furthermore, the data channels starve the control channel on high transmission load on the ldisc. Introduce an additional control channel data queue to prevent timeouts and link hangups during ldisc congestion. This is being processed before the user channel data queue in gsm_data_kick(), i.e. with the highest priority. Put the queue to ldisc data path into a workqueue and trigger it whenever new data has been put into the transmission queue. Change gsm_dlci_data_sweep() accordingly to fill up the transmission queue until TX_THRESH_HI. This solves the locking issue, keeps latency low and provides good performance on high data load. Note that now all pa
. This solves the locking issue, keeps latency low and provides good performance on high data load. Note that now all packets from a DLCI are removed from the internal queue if the associated DLCI was closed. This ensures that no data is sent by the introduced write task to an already closed DLCI. BUG: spinlock recursion on CPU#0, test_v24_loop/124 lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0 CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x34/0x44 do_raw_spin_lock+0x76/0xa0 _raw_spin_lock_irqsave+0x72/0x80 uart_wr
4/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x34/0x44 do_raw_spin_lock+0x76/0xa0 _raw_spin_lock_irqsave+0x72/0x80 uart_write_room+0x3b/0xc0 gsm_data_kick+0x14b/0x240 [n_gsm] gsmld_write_wakeup+0x35/0x70 [n_gsm] tty_wakeup+0x53/0x60 tty_port_default_wakeup+0x1b/0x30 serial8250_tx_chars+0x12f/0x220 serial8250_handle_irq.part.0+0xfe/0x150 serial8250_default_handle_irq+0x48/0x80 serial8250_interrupt+0x56/0xa0 __handle_irq_event_percpu+0x78/0x1f0 handle_irq_event+0x34/0x70 handle_fasteoi_irq+0x90/0x1e0 __common_interrupt+0x69/0x100 common_interrupt+0x48/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:__do_softirq+0x83/0x34e Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d e
0x1e/0x40 RIP: 0010:__do_softirq+0x83/0x34e Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 61 80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00 RSP: 0018:ffffc90000003f98 EFLAGS: 00000286 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7 RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000 ? __do_softirq+0x73/0x34e irq_exit_rcu+0xb5/0x100 common_interrupt+0xa4/0xc0 </IRQ
000000000000000 R15: 0000000000000000 ? __do_softirq+0x73/0x34e irq_exit_rcu+0xb5/0x100 common_interrupt+0xa4/0xc0 </IRQ> <TASK> asm_common_interrupt+0x1e/0x40 RIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50 Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff 48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 <e8> 3d 97 33 ff 65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44 RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001 RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0
001 RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8 ? _raw_spin_unlock_irqrestore+0x23/0x50 gsmtty_write+0x65/0x80 [n_gsm] n_tty_write+0x33f/0x530 ? swake_up_all+0xe0/0xe0 file_tty_write.constprop.0+0x1b1/0x320 ? n_tty_flush_buffer+0xb0/0xb0 new_sync_write+0x10c/0x190 vfs_write+0x282/0x310 ksys_write+0x68/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f3e5e35c15c Code: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24 ---truncated--- References: - https://git.kernel.org/stable/c/c165698c9919b000bdbe73859d3bb7b3
5 ff ff ff 89 ef 89 44 24 ---truncated--- References: - https://git.kernel.org/stable/c/c165698c9919b000bdbe73859d3bb7b33bdb9223 - https://git.kernel.org/stable/c/7962a4b900099cf90e02859bb297f2c618d8d940 - https://git.kernel.org/stable/c/0af021678d5d30c31f5a6b631f404ead3575212a
CVE ID: CVE-2022-50117 State: PUBLISHED Published: 2025-06-18T11:02:47.994Z Last Updated: 2025-06-18T11:02:47.994Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vfio: Split migration ops from main device ops vfio core checks whether the driver sets some migration op (e.g. set_state/get_state) and accordingly calls its op. However, currently mlx5 driver sets the above ops without regards to its migration caps. This might lead to unexpected usage/Oops if user space may call to the above ops even if the driver doesn't support migration. As for example, the migration state_mutex is not initialized in that case. The cleanest way to
oesn't support migration. As for example, the migration state_mutex is not initialized in that case. The cleanest way to manage that seems to split the migration ops from the main device ops, this will let the driver setting them separately from the main ops when it's applicable. As part of that, validate ops construction on registration and include a check for VFIO_MIGRATION_STOP_COPY since the uAPI claims it must be set in migration_flags. HISI driver was changed as well to match this scheme. This scheme may enable down the road to come with some extra group of ops (e.g. DMA log) that can be set without regards to the other options based on driver caps. References: - https://git.kernel.org
DMA log) that can be set without regards to the other options based on driver caps. References: - https://git.kernel.org/stable/c/bba6b12d73d36e0ddbc2c3ac5668a667b00d4345 - https://git.kernel.org/stable/c/6e97eba8ad8748fabb795cffc5d9e1a7dcfd7367
CVE ID: CVE-2022-50118 State: PUBLISHED Published: 2025-06-18T11:02:48.672Z Last Updated: 2025-06-18T11:02:48.672Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") added a new function "pmi_irq_pending" in hw_irq.h. This function is to check if there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is used in power_pmu_disable in a WARN_ON. The intention here is to provide a warning if there is PMI pending, but no
s is used in power_pmu_disable in a WARN_ON. The intention here is to provide a warning if there is PMI pending, but no counter is found overflown. During some of the perf runs, below warning is hit: WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0 Modules linked in: ----- NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0 LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 Call Trace: [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable) [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60 [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100 [c000000baffcfc80] [c0000000003e353c] __perf
0 [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100 [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240 [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140 [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0 [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300 [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100 [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40 [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250 [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0 [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x
ffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0 [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0 [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80 [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0 [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140 [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8 [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0 [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220 This means that there is no PMC overflown among the active events in the PMU, but there is a PMU pending in Paca. The function "any_pmc_overflown" checks the PMCs on active events in cpuhw->n_ev
MU, but there is a PMU pending in Paca. The function "any_pmc_overflown" checks the PMCs on active events in cpuhw->n_events. Code snippet: <<>> if (any_pmc_overflown(cpuhw)) clear_pmi_irq_pending(); else WARN_ON(pmi_irq_pending()); <<>> Here the PMC overflown is not from active event. Example: When we do perf record, default cycles and instructions will be running on PMC6 and PMC5 respectively. It could happen that overflowed event is currently not active and pending PMI is for the inactive event. Debug logs from trace_printk: <<>> any_pmc_overflown: idx is 5: pmc value is 0xd9a power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011 <<>> Here active PMC
0xd9a power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011 <<>> Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011). When we handle PMI interrupt for such cases, if the PMC overflown is from inactive event, it will be ignored. Reference commit: commit bc09c219b2e6 ("powerpc/perf: Fix finding overflowed PMC in interrupt") Patch addresses two changes: 1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); ) We were printing warning if no PMC is found overflown among active PMU events, but PMI pending in PACA. But this could happen in cases where PMC overflown is not in active PMC. An inactive event could have caused the overf
. But this could happen in cases where PMC overflown is not in active PMC. An inactive event could have caused the overflow. Hence the warning is not needed. To know pending PMI is from an inactive event, we need to loop through all PMC's which will cause more SPR reads via mfspr and increase in context switch. Also in existing function: perf_event_interrupt, already we ignore PMI's overflown when it is from an inactive PMC. 2) Fix 2: optimization in clearing pending PMI. Currently we check for any active PMC overflown before clearing PMI pending in Paca. This is causing additional SP ---truncated--- References: - https://git.kernel.org/stable/c/875b2bf469d094754ac2ba9af91dcd529eb12bf6 - htt
ditional SP ---truncated--- References: - https://git.kernel.org/stable/c/875b2bf469d094754ac2ba9af91dcd529eb12bf6 - https://git.kernel.org/stable/c/87b1a9175f08313f40fcb6d6dc536dbe451090eb - https://git.kernel.org/stable/c/0a24ea26c3278216642a43291df7976a73a0a7ee - https://git.kernel.org/stable/c/7e83af3dd4a3afca8f83ffde518cafd52f45b830 - https://git.kernel.org/stable/c/890005a7d98f7452cfe86dcfb2aeeb7df01132ce
CVE ID: CVE-2022-50119 State: PUBLISHED Published: 2025-06-18T11:02:49.264Z Last Updated: 2025-06-18T11:02:49.264Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rpmsg: Fix possible refcount leak in rpmsg_register_device_override() rpmsg_register_device_override need to call put_device to free vch when driver_set_override fails. Fix this by adding a put_device() to the error path. References: - https://git.kernel.org/stable/c/280ae5a028ef5d14ef9277746a3026a30aaebe4f - https://git.kernel.org/stable/c/c449b28e437d18ae807479c4ac6b69d87b287c79 - https://git.kernel.org/stable/c/01e6885b75e25a2dd0726455ef18ef9ce5e7dc87 - https://git.
7d18ae807479c4ac6b69d87b287c79 - https://git.kernel.org/stable/c/01e6885b75e25a2dd0726455ef18ef9ce5e7dc87 - https://git.kernel.org/stable/c/3fdd5b2bb09fc2b5bf3504778f51c89bb48c097f - https://git.kernel.org/stable/c/d4c8bf5635c4bedaf2470761ced1f502b2d5434e - https://git.kernel.org/stable/c/c29335612ff44df979678a38e1f55c62004f421c - https://git.kernel.org/stable/c/d7bd416d35121c95fe47330e09a5c04adbc5f928
CVE ID: CVE-2022-50120 State: PUBLISHED Published: 2025-06-18T11:02:49.845Z Last Updated: 2025-06-18T11:02:49.845Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_rproc: Fix refcount leak in imx_rproc_addr_init of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. This function has two paths missing of_node_put(). References: - https://git.kernel.org/stable/c/0dc1663e3fc22c72e1ab33be7701a0d51cca84ef - https://git.kernel.org/stable/c/d8ac68927856c3a6d197a95be73c92ec0bd4b012 - https://git.kernel.org/stable/c/16da9f84e26f89e58cac194ff19fefd9de
g/stable/c/d8ac68927856c3a6d197a95be73c92ec0bd4b012 - https://git.kernel.org/stable/c/16da9f84e26f89e58cac194ff19fefd9de27d975 - https://git.kernel.org/stable/c/61afafe8b938bc74841cf4b1a73dd08b9d287c5a
CVE ID: CVE-2022-50121 State: PUBLISHED Published: 2025-06-18T11:02:50.472Z Last Updated: 2025-06-18T11:02:50.472Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init Every iteration of for_each_available_child_of_node() decrements the reference count of the previous node. When breaking early from a for_each_available_child_of_node() loop, we need to explicitly call of_node_put() on the child node. Add missing of_node_put() to avoid refcount leak. References: - https://git.kernel.org/stable/c/75358732af9b26acfe3e609943290bcba13330fc - https://git.kernel.org/stable/c/cf112
nces: - https://git.kernel.org/stable/c/75358732af9b26acfe3e609943290bcba13330fc - https://git.kernel.org/stable/c/cf112a52d758092ca3d5ebdad51dd17bda5ba3e5 - https://git.kernel.org/stable/c/61cd8cd3b6b33c7eae3b45cf783b114f2ae53528 - https://git.kernel.org/stable/c/3f83c4cf1b78331c23876977aa7b9151aff2f9e1 - https://git.kernel.org/stable/c/fa220c05d282e7479abe08b54e3bdffd06c25e97
CVE ID: CVE-2022-50122 State: PUBLISHED Published: 2025-06-18T11:02:51.099Z Last Updated: 2025-06-18T11:02:51.099Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8173-rt5650: Fix refcount leak in mt8173_rt5650_dev_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Fix refcount leak in some error paths. References: - https://git.kernel.org/stable/c/06ace427953f5036b64aed658f0055f65d76fd27 - https://git.kernel.org/stable/c/e024a24fb264523149658c10c76bb363b3d0004d - https://git.kernel.org/stable/c/79f566907d27abbd7600cebe51def5081d57
stable/c/e024a24fb264523149658c10c76bb363b3d0004d - https://git.kernel.org/stable/c/79f566907d27abbd7600cebe51def5081d5796b5 - https://git.kernel.org/stable/c/403d46971936f9f704b91cecffe66e44aa39e915 - https://git.kernel.org/stable/c/994f2edeeb2114bb22b62741cb8fb030fc7e5441 - https://git.kernel.org/stable/c/e38e4952ac7a316c9002af30980d6aa850214474 - https://git.kernel.org/stable/c/5ec83aa7a9e5bcca80ccd49978916feb4e0ffc07 - https://git.kernel.org/stable/c/efe2178d1a32492f99e7f1f2568eea5c88a85729