xamxte/cve-to-cwe huggingface dataset:
CVE-2022-49979: In the Linux kernel, the following vulnerability has been resolved:  net: fix refcount bug in sk_psock_get (2)  Syzkaller reports refcount bug as follows: ------------[ cut here ]------------ refcount_t: saturated; leaking memory. WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19 Modules linked in: CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0  <TASK>  __refcount_add_not_zero include/linux/refcount.h:163 [inline]  __refcount_inc_not_zero include/linux/refcount.h:227 [inline]  refcount_inc_not_zero include/linux/refcount.h:245 [inline]  sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439  tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091  tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983  tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057  tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659  tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682  sk_backlog_rcv include/net/sock.h:1061 [inline]  __release_sock+0x134/0x3b0 net/core/sock.c:2849  release_sock+0x54/0x1b0 net/core/sock.c:3404  inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909  __sys_shutdown_sock net/socket.c:2331 [inline]  __sys_shutdown_sock net/socket.c:2325 [inline]  __sys_shutdown+0xf1/0x1b0 net/socket.c:2343  __do_sys_shutdown net/socket.c:2351 [inline]  __se_sys_shutdown net/socket.c:2349 [inline]  __x64_sys_shutdown+0x50/0x70 net/socket.c:2349  do_syscall_x64 arch/x86/entry/common.c:50 [inline]  do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80  entry_SYSCALL_64_after_hwframe+0x46/0xb0  </TASK>  During SMC fallback process in connect syscall, kernel will replaces TCP with SMC. In order to forward wakeup smc socket waitqueue after fallback, kernel will sets clcsk->sk_user_data to origin smc socket in smc_fback_replace_callbacks().  Later, in shutdown syscall, kernel will calls sk_psock_get(), which treats the clcsk->sk_user_data as psock type, triggering the refcnt warning.  So, the root cause is that smc and psock, both will use sk_user_data field. So they will mismatch this field easily.  This patch solves it by using another bit(defined as SK_USER_DATA_PSOCK) in PTRMASK, to mark whether sk_user_data points to a psock object or not. This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e ("net, sk_msg: Clear sk_user_data pointer on clone if tagged").  For there will possibly be more flags in the sk_user_data field, this patch also refactor sk_user_data flags code to be more generic to improve its maintainability.
CVE-2022-49993: In the Linux kernel, the following vulnerability has been resolved:  loop: Check for overflow while configuring loop  The userspace can configure a loop using an ioctl call, wherein a configuration of type loop_config is passed (see lo_ioctl()'s case on line 1550 of drivers/block/loop.c). This proceeds to call loop_configure() which in turn calls loop_set_status_from_info() (see line 1050 of loop.c), passing &config->info which is of type loop_info64*. This function then sets the appropriate values, like the offset.  loop_device has lo_offset of type loff_t (see line 52 of loop.c), which is typdef-chained to long long, whereas loop_info64 has lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h).  The function directly copies offset from info to the device as follows (See line 980 of loop.c):  lo->lo_offset = info->lo_offset;  This results in an overflow, which triggers a warning in iomap_iter() due to a call to iomap_iter_done() which has:  WARN_ON_ONCE(iter->iomap.offset > iter->pos);  Thus, check for negative value during loop_set_status_from_info().  Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e
CVE-2022-50001: In the Linux kernel, the following vulnerability has been resolved:  netfilter: nft_tproxy: restrict to prerouting hook  TPROXY is only allowed from prerouting, but nft_tproxy doesn't check this. This fixes a crash (null dereference) when using tproxy from e.g. output.
CVE-2022-50007: In the Linux kernel, the following vulnerability has been resolved:  xfrm: fix refcount leak in __xfrm_policy_check()  The issue happens on an error path in __xfrm_policy_check(). When the fetching process of the object `pols[1]` fails, the function simply returns 0, forgetting to decrement the reference count of `pols[0]`, which is incremented earlier by either xfrm_sk_policy_lookup() or xfrm_policy_lookup(). This may result in memory leaks.  Fix it by decreasing the reference count of `pols[0]` in that path.
CVE-2022-50012: In the Linux kernel, the following vulnerability has been resolved:  powerpc/64: Init jump labels before parse_early_param()  On 64-bit, calling jump_label_init() in setup_feature_keys() is too late because static keys may be used in subroutines of parse_early_param() which is again subroutine of early_init_devtree().  For example booting with "threadirqs":    static_key_enable_cpuslocked(): static key '0xc000000002953260' used before call to jump_label_init()   WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120   ...   NIP static_key_enable_cpuslocked+0xfc/0x120   LR  static_key_enable_cpuslocked+0xf8/0x120   Call Trace:     static_key_enable_cpuslocked+0xf8/0x120 (unreliable)     static_key_enable+0x30/0x50     setup_forced_irqthreads+0x28/0x40     do_early_param+0xa0/0x108     parse_args+0x290/0x4e0     parse_early_options+0x48/0x5c     parse_early_param+0x58/0x84     early_init_devtree+0xd4/0x518     early_setup+0xb4/0x214  So call jump_label_init() just before parse_early_param() in early_init_devtree().  [mpe: Add call trace to change log and minor wording edits.]
CVE-2022-50017: In the Linux kernel, the following vulnerability has been resolved:  mips: cavium-octeon: Fix missing of_node_put() in octeon2_usb_clocks_start  We should call of_node_put() for the reference 'uctl_node' returned by of_get_parent() which will increase the refcount. Otherwise, there will be a refcount leak bug.
CVE-2022-50019: In the Linux kernel, the following vulnerability has been resolved:  tty: serial: Fix refcount leak bug in ucc_uart.c  In soc_info(), of_find_node_by_type() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
CVE-2022-50023: In the Linux kernel, the following vulnerability has been resolved:  dmaengine: dw-axi-dmac: ignore interrupt if no descriptor  If the channel has no descriptor and the interrupt is raised then the kernel will OOPS. Check the result of vchan_next_desc() in the handler axi_chan_block_xfer_complete() to avoid the error happening.
CVE-2022-50028: In the Linux kernel, the following vulnerability has been resolved:  gadgetfs: ep_io - wait until IRQ finishes  after usb_ep_queue() if wait_for_completion_interruptible() is interrupted we need to wait until IRQ gets finished.  Otherwise complete() from epio_complete() can corrupt stack.
CVE-2022-50032: In the Linux kernel, the following vulnerability has been resolved:  usb: renesas: Fix refcount leak bug  In usbhs_rza1_hardware_init(), of_find_node_by_name() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
CVE-2022-50033: In the Linux kernel, the following vulnerability has been resolved:  usb: host: ohci-ppc-of: Fix refcount leak bug  In ohci_hcd_ppc_of_probe(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
CVE-2022-50038: In the Linux kernel, the following vulnerability has been resolved:  drm/meson: Fix refcount bugs in meson_vpu_has_available_connectors()  In this function, there are two refcount leak bugs: (1) when breaking out of for_each_endpoint_of_node(), we need call the of_node_put() for the 'ep'; (2) we should call of_node_put() for the reference returned by of_graph_get_remote_port() when it is not used anymore.
CVE-2022-50039: In the Linux kernel, the following vulnerability has been resolved:  stmmac: intel: Add a missing clk_disable_unprepare() call in intel_eth_pci_remove()  Commit 09f012e64e4b ("stmmac: intel: Fix clock handling on error and remove paths") removed this clk_disable_unprepare()  This was partly revert by commit ac322f86b56c ("net: stmmac: Fix clock handling on remove path") which removed this clk_disable_unprepare() because: "    While unloading the dwmac-intel driver, clk_disable_unprepare() is    being called twice in stmmac_dvr_remove() and    intel_eth_pci_remove(). This causes kernel panic on the second call. "  However later on, commit 5ec55823438e8 ("net: stmmac: add clocks management for gmac driver") has updated stmmac_dvr_remove() which do not call clk_disable_unprepare() anymore.  So this call should now be called from intel_eth_pci_remove().
CVE-2022-50043: In the Linux kernel, the following vulnerability has been resolved:  net: fix potential refcount leak in ndisc_router_discovery()  The issue happens on specific paths in the function. After both the object `rt` and `neigh` are grabbed successfully, when `lifetime` is nonzero but the metric needs change, the function just deletes the route and set `rt` to NULL. Then, it may try grabbing `rt` and `neigh` again if above conditions hold. The function simply overwrite `neigh` if succeeds or returns if fails, without decreasing the reference count of previous `neigh`. This may result in memory leaks.  Fix it by decrementing the reference count of `neigh` in place.
CVE-2022-50055: In the Linux kernel, the following vulnerability has been resolved:  iavf: Fix adminq error handling  iavf_alloc_asq_bufs/iavf_alloc_arq_bufs allocates with dma_alloc_coherent memory for VF mailbox. Free DMA regions for both ASQ and ARQ in case error happens during configuration of ASQ/ARQ registers. Without this change it is possible to see when unloading interface: 74626.583369: dma_debug_device_change: device driver has pending DMA allocations while released from device [count=32] One of leaked entries details: [device address=0x0000000b27ff9000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent]
CVE-2022-50059: In the Linux kernel, the following vulnerability has been resolved:  ceph: don't leak snap_rwsem in handle_cap_grant  When handle_cap_grant is called on an IMPORT op, then the snap_rwsem is held and the function is expected to release it before returning. It currently fails to do that in all cases which could lead to a deadlock.
CVE-2022-50061: In the Linux kernel, the following vulnerability has been resolved:  pinctrl: nomadik: Fix refcount leak in nmk_pinctrl_dt_subnode_to_map  of_parse_phandle() 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."
CVE-2022-50070: In the Linux kernel, the following vulnerability has been resolved:  mptcp: do not queue data on closed subflows  Dipanjan reported a syzbot splat at close time:  WARNING: CPU: 1 PID: 10818 at net/ipv4/af_inet.c:153 inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153 Modules linked in: uio_ivshmem(OE) uio(E) CPU: 1 PID: 10818 Comm: kworker/1:16 Tainted: G           OE 5.19.0-rc6-g2eae0556bb9d #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153 Code: 21 02 00 00 41 8b 9c 24 28 02 00 00 e9 07 ff ff ff e8 34 4d 91 f9 89 ee 4c 89 e7 e8 4a 47 60 ff e9 a6 fc ff ff e8 20 4d 91 f9 <0f> 0b e9 84 fe ff ff e8 14 4d 91 f9 0f 0b e9 d4 fd ff ff e8 08 4d RSP: 0018:ffffc9001b35fa78 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000002879d0 RCX: ffff8881326f3b00 RDX: 0000000000000000 RSI: ffff8881326f3b00 RDI: 0000000000000002 RBP: ffff888179662674 R08: ffffffff87e983a0 R09: 0000000000000000 R10: 0000000000000005 R11: 00000000000004ea R12: ffff888179662400 R13: ffff888179662428 R14: 0000000000000001 R15: ffff88817e38e258 FS:  0000000000000000(0000) GS:ffff8881f5f00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020007bc0 CR3: 0000000179592000 CR4: 0000000000150ee0 Call Trace:  <TASK>  __sk_destruct+0x4f/0x8e0 net/core/sock.c:2067  sk_destruct+0xbd/0xe0 net/core/sock.c:2112  __sk_free+0xef/0x3d0 net/core/sock.c:2123  sk_free+0x78/0xa0 net/core/sock.c:2134  sock_put include/net/sock.h:1927 [inline]  __mptcp_close_ssk+0x50f/0x780 net/mptcp/protocol.c:2351  __mptcp_destroy_sock+0x332/0x760 net/mptcp/protocol.c:2828  mptcp_worker+0x5d2/0xc90 net/mptcp/protocol.c:2586  process_one_work+0x9cc/0x1650 kernel/workqueue.c:2289  worker_thread+0x623/0x1070 kernel/workqueue.c:2436  kthread+0x2e9/0x3a0 kernel/kthread.c:376  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302  </TASK>  The root cause of the problem is that an mptcp-level (re)transmit can race with mptcp_close() and the packet scheduler checks the subflow state before acquiring the socket lock: we can try to (re)transmit on an already closed ssk.  Fix the issue checking again the subflow socket status under the subflow socket lock protection. Additionally add the missing check for the fallback-to-tcp case.
CVE-2022-50071: In the Linux kernel, the following vulnerability has been resolved:  mptcp: move subflow cleanup in mptcp_destroy_common()  If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATE eBPF program, the MPTCP protocol ends-up leaking all the subflows: the related cleanup happens in __mptcp_destroy_sock() that is not invoked in such code path.  Address the issue moving the subflow sockets cleanup in the mptcp_destroy_common() helper, which is invoked in every msk cleanup path.  Additionally get rid of the intermediate list_splice_init step, which is an unneeded relic from the past.  The issue is present since before the reported root cause commit, but any attempt to backport the fix before that hash will require a complete rewrite.
CVE-2022-50077: In the Linux kernel, the following vulnerability has been resolved:  apparmor: fix reference count leak in aa_pivotroot()  The aa_pivotroot() function has a reference counting bug in a specific path. When aa_replace_current_label() returns on success, the function forgets to decrement the reference count of “target”, which is increased earlier by build_pivotroot(), causing a reference leak.  Fix it by decreasing the refcount of “target” in that path.
CVE-2022-50085: In the Linux kernel, the following vulnerability has been resolved:  dm raid: fix address sanitizer warning in raid_resume  There is a KASAN warning in raid_resume when running the lvm test lvconvert-raid.sh. The reason for the warning is that mddev->raid_disks is greater than rs->raid_disks, so the loop touches one entry beyond the allocated length.
CVE-2022-50086: In the Linux kernel, the following vulnerability has been resolved:  block: don't allow the same type rq_qos add more than once  In our test of iocost, we encountered some list add/del corruptions of inner_walk list in ioc_timer_fn.  The reason can be described as follows:  cpu 0     cpu 1 ioc_qos_write    ioc_qos_write  ioc = q_to_ioc(queue); if (!ioc) {         ioc = kzalloc();      ioc = q_to_ioc(queue);      if (!ioc) {       ioc = kzalloc();       ...       rq_qos_add(q, rqos);      }         ...         rq_qos_add(q, rqos);         ... }  When the io.cost.qos file is written by two cpus concurrently, rq_qos may be added to one disk twice. In that case, there will be two iocs enabled and running on one disk. They own different iocgs on their active list. In the ioc_timer_fn function, because of the iocgs from two iocs have the same root iocg, the root iocg's walk_list may be overwritten by each other and this leads to list add/del corruptions in building or destroying the inner_walk list.  And so far, the blk-rq-qos framework works in case that one instance for one type rq_qos per queue by default. This patch make this explicit and also fix the crash above.
CVE-2022-50097: In the Linux kernel, the following vulnerability has been resolved:  video: fbdev: s3fb: Check the size of screen before memset_io()  In the function s3fb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug:  [   54.083733] BUG: unable to handle page fault for address: ffffc90003000000 [   54.083742] #PF: supervisor write access in kernel mode [   54.083744] #PF: error_code(0x0002) - not-present page [   54.083760] RIP: 0010:memset_orig+0x33/0xb0 [   54.083782] Call Trace: [   54.083788]  s3fb_set_par+0x1ec6/0x4040 [   54.083806]  fb_set_var+0x604/0xeb0 [   54.083836]  do_fb_ioctl+0x234/0x670  Fix the this by checking the value of 'screen_size' before memset_io().
CVE-2022-50098: In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts  Ensure SRB is returned during I/O timeout error escalation. If that is not possible fail the escalation path.  Following crash stack was seen:  BUG: unable to handle kernel paging request at 0000002f56aa90f8 IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx] Call Trace:  ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx]  ? qla2x00_start_sp+0x116/0x1170 [qla2xxx]  ? dma_pool_alloc+0x1d6/0x210  ? mempool_alloc+0x54/0x130  ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx]  ? qla_do_work+0x2d/0x40 [qla2xxx]  ? process_one_work+0x14c/0x390
CVE-2022-50099: In the Linux kernel, the following vulnerability has been resolved:  video: fbdev: arkfb: Check the size of screen before memset_io()  In the function arkfb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug:  [  659.399066] BUG: unable to handle page fault for address: ffffc90003000000 [  659.399077] #PF: supervisor write access in kernel mode [  659.399079] #PF: error_code(0x0002) - not-present page [  659.399094] RIP: 0010:memset_orig+0x33/0xb0 [  659.399116] Call Trace: [  659.399122]  arkfb_set_par+0x143f/0x24c0 [  659.399130]  fb_set_var+0x604/0xeb0 [  659.399161]  do_fb_ioctl+0x234/0x670 [  659.399189]  fb_ioctl+0xdd/0x130  Fix the this by checking the value of 'screen_size' before memset_io().
CVE-2022-50100: In the Linux kernel, the following vulnerability has been resolved:  sched/core: Do not requeue task on CPU excluded from cpus_mask  The following warning was triggered on a large machine early in boot on a distribution kernel but the same problem should also affect mainline.     WARNING: CPU: 439 PID: 10 at ../kernel/workqueue.c:2231 process_one_work+0x4d/0x440    Call Trace:     <TASK>     rescuer_thread+0x1f6/0x360     kthread+0x156/0x180     ret_from_fork+0x22/0x30     </TASK>  Commit c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") optimises ttwu by queueing a task that is descheduling on the wakelist, but does not check if the task descheduling is still allowed to run on that CPU.  In this warning, the problematic task is a workqueue rescue thread which checks if the rescue is for a per-cpu workqueue and running on the wrong CPU. While this is early in boot and it should be possible to create workers, the rescue thread may still used if the MAYDAY_INITIAL_TIMEOUT is reached or MAYDAY_INTERVAL and on a sufficiently large machine, the rescue thread is being used frequently.  Tracing confirmed that the task should have migrated properly using the stopper thread to handle the migration. However, a parallel wakeup from udev running on another CPU that does not share CPU cache observes p->on_cpu and uses task_cpu(p), queues the task on the old CPU and triggers the warning.  Check that the wakee task that is descheduling is still allowed to run on its current CPU and if not, wait for the descheduling to complete and select an allowed CPU.
CVE-2022-50101: In the Linux kernel, the following vulnerability has been resolved:  video: fbdev: vt8623fb: Check the size of screen before memset_io()  In the function vt8623fb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug:  [  583.339036] BUG: unable to handle page fault for address: ffffc90005000000 [  583.339049] #PF: supervisor write access in kernel mode [  583.339052] #PF: error_code(0x0002) - not-present page [  583.339074] RIP: 0010:memset_orig+0x33/0xb0 [  583.339110] Call Trace: [  583.339118]  vt8623fb_set_par+0x11cd/0x21e0 [  583.339146]  fb_set_var+0x604/0xeb0 [  583.339181]  do_fb_ioctl+0x234/0x670 [  583.339209]  fb_ioctl+0xdd/0x130  Fix the this by checking the value of 'screen_size' before memset_io().
CVE-2022-50104: In the Linux kernel, the following vulnerability has been resolved:  powerpc/xive: Fix refcount leak in xive_get_max_prio  of_find_node_by_path() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
CVE-2022-50105: In the Linux kernel, the following vulnerability has been resolved:  powerpc/spufs: Fix refcount leak in spufs_init_isolated_loader  of_find_node_by_path() returns remote device nodepointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
CVE-2022-50106: In the Linux kernel, the following vulnerability has been resolved:  powerpc/cell/axon_msi: Fix refcount leak in setup_msi_msg_address  of_get_next_parent() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() in the error path to avoid refcount leak.
CVE-2022-50108: 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.
CVE-2022-50109: 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.
CVE-2022-50111: 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.
CVE-2022-50112: 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.
CVE-2022-50113: 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.
CVE-2022-50114: 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]
CVE-2022-50119: 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.