xamxte/cve-to-cwe huggingface dataset:
CVE-2025-68732: In the Linux kernel, the following vulnerability has been resolved:  gpu: host1x: Fix race in syncpt alloc/free  Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking.  This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release.  Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.
CVE-2025-68733: In the Linux kernel, the following vulnerability has been resolved:  smack: fix bug: unprivileged task can create labels  If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current  This occurs because do_setattr() imports the provided label in advance, before checking "relabel-self" list.  This change ensures that the "relabel-self" list is checked before importing the label.
CVE-2025-68734: In the Linux kernel, the following vulnerability has been resolved:  isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()  In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when setup_instance() fails with an error code. Fix that by freeing the urb before freeing the hw structure. Also change the error paths to use the goto ladder style.  Compile tested only. Issue found using a prototype static analysis tool.
CVE-2022-50712: In the Linux kernel, the following vulnerability has been resolved:  devlink: hold region lock when flushing snapshots  Netdevsim triggers a splat on reload, when it destroys regions with snapshots pending:    WARNING: CPU: 1 PID: 787 at net/core/devlink.c:6291 devlink_region_snapshot_del+0x12e/0x140   CPU: 1 PID: 787 Comm: devlink Not tainted 6.1.0-07460-g7ae9888d6e1c #580   RIP: 0010:devlink_region_snapshot_del+0x12e/0x140   Call Trace:    <TASK>    devl_region_destroy+0x70/0x140    nsim_dev_reload_down+0x2f/0x60 [netdevsim]    devlink_reload+0x1f7/0x360    devlink_nl_cmd_reload+0x6ce/0x860    genl_family_rcv_msg_doit.isra.0+0x145/0x1c0  This is the locking assert in devlink_region_snapshot_del(), we're supposed to be holding the region->snapshot_lock here.
CVE-2022-50713: In the Linux kernel, the following vulnerability has been resolved:  clk: visconti: Fix memory leak in visconti_register_pll()  @pll->rate_table has allocated memory by kmemdup(), if clk_hw_register() fails, it should be freed, otherwise it will cause memory leak issue, this patch fixes it.
CVE-2022-50714: In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: mt7921e: fix rmmod crash in driver reload test  In insmod/rmmod stress test, the following crash dump shows up immediately. The problem is caused by missing mt76_dev in mt7921_pci_remove(). We should make sure the drvdata is ready before probe() finished.  [168.862789] ================================================================== [168.862797] BUG: KASAN: user-memory-access in try_to_grab_pending+0x59/0x480 [168.862805] Write of size 8 at addr 0000000000006df0 by task rmmod/5361 [168.862812] CPU: 7 PID: 5361 Comm: rmmod Tainted: G           OE     5.19.0-rc6 #1 [168.862816] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, 05/04/2020 [168.862820] Call Trace: [168.862822]  <TASK> [168.862825]  dump_stack_lvl+0x49/0x63 [168.862832]  print_report.cold+0x493/0x6b7 [168.862845]  kasan_report+0xa7/0x120 [168.862857]  kasan_check_range+0x163/0x200 [168.862861]  __kasan_check_write+0x14/0x20 [168.862866]  try_to_grab_pending+0x59/0x480 [168.862870]  __cancel_work_timer+0xbb/0x340 [168.862898]  cancel_work_sync+0x10/0x20 [168.862902]  mt7921_pci_remove+0x61/0x1c0 [mt7921e] [168.862909]  pci_device_remove+0xa3/0x1d0 [168.862914]  device_remove+0xc4/0x170 [168.862920]  device_release_driver_internal+0x163/0x300 [168.862925]  driver_detach+0xc7/0x1a0 [168.862930]  bus_remove_driver+0xeb/0x2d0 [168.862935]  driver_unregister+0x71/0xb0 [168.862939]  pci_unregister_driver+0x30/0x230 [168.862944]  mt7921_pci_driver_exit+0x10/0x1b [mt7921e] [168.862949]  __x64_sys_delete_module+0x2f9/0x4b0 [168.862968]  do_syscall_64+0x38/0x90 [168.862973]  entry_SYSCALL_64_after_hwframe+0x63/0xcd  Test steps: 1. insmode 2. do not ifup 3. rmmod quickly (within 1 second)
CVE-2022-50715: In the Linux kernel, the following vulnerability has been resolved:  md/raid1: stop mdx_raid1 thread when raid1 array run failed  fail run raid1 array when we assemble array with the inactive disk only, but the mdx_raid1 thread were not stop, Even if the associated resources have been released. it will caused a NULL dereference when we do poweroff.  This causes the following Oops:     [  287.587787] BUG: kernel NULL pointer dereference, address: 0000000000000070     [  287.594762] #PF: supervisor read access in kernel mode     [  287.599912] #PF: error_code(0x0000) - not-present page     [  287.605061] PGD 0 P4D 0     [  287.607612] Oops: 0000 [#1] SMP NOPTI     [  287.611287] CPU: 3 PID: 5265 Comm: md0_raid1 Tainted: G     U            5.10.146 #0     [  287.619029] Hardware name: xxxxxxx/To be filled by O.E.M, BIOS 5.19 06/16/2022     [  287.626775] RIP: 0010:md_check_recovery+0x57/0x500 [md_mod]     [  287.632357] Code: fe 01 00 00 48 83 bb 10 03 00 00 00 74 08 48 89 ......     [  287.651118] RSP: 0018:ffffc90000433d78 EFLAGS: 00010202     [  287.656347] RAX: 0000000000000000 RBX: ffff888105986800 RCX: 0000000000000000     [  287.663491] RDX: ffffc90000433bb0 RSI: 00000000ffffefff RDI: ffff888105986800     [  287.670634] RBP: ffffc90000433da0 R08: 0000000000000000 R09: c0000000ffffefff     [  287.677771] R10: 0000000000000001 R11: ffffc90000433ba8 R12: ffff888105986800     [  287.684907] R13: 0000000000000000 R14: fffffffffffffe00 R15: ffff888100b6b500     [  287.692052] FS:  0000000000000000(0000) GS:ffff888277f80000(0000) knlGS:0000000000000000     [  287.700149] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033     [  287.705897] CR2: 0000000000000070 CR3: 000000000320a000 CR4: 0000000000350ee0     [  287.713033] Call Trace:     [  287.715498]  raid1d+0x6c/0xbbb [raid1]     [  287.719256]  ? __schedule+0x1ff/0x760     [  287.722930]  ? schedule+0x3b/0xb0     [  287.726260]  ? schedule_timeout+0x1ed/0x290     [  287.730456]  ? __switch_to+0x11f/0x400     [  287.734219]  md_thread+0xe9/0x140 [md_mod]     [  287.738328]  ? md_thread+0xe9/0x140 [md_mod]     [  287.742601]  ? wait_woken+0x80/0x80     [  287.746097]  ? md_register_thread+0xe0/0xe0 [md_mod]     [  287.751064]  kthread+0x11a/0x140     [  287.754300]  ? kthread_park+0x90/0x90     [  287.757974]  ret_from_fork+0x1f/0x30  In fact, when raid1 array run fail, we need to do md_unregister_thread() before raid1_free().
CVE-2022-50717: In the Linux kernel, the following vulnerability has been resolved:  nvmet-tcp: add bounds check on Transfer Tag  ttag is used as an index to get cmd in nvmet_tcp_handle_h2c_data_pdu(), add a bounds check to avoid out-of-bounds access.
CVE-2022-50718: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: fix pci device refcount leak  As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put().  So before returning from amdgpu_device_resume|suspend_display_audio(), pci_dev_put() is called to avoid refcount leak.
CVE-2022-50719: In the Linux kernel, the following vulnerability has been resolved:  ALSA: line6: fix stack overflow in line6_midi_transmit  Correctly calculate available space including the size of the chunk buffer. This fixes a buffer overflow when multiple MIDI sysex messages are sent to a PODxt device.
CVE-2022-50722: In the Linux kernel, the following vulnerability has been resolved:  media: ipu3-imgu: Fix NULL pointer dereference in active selection access  What the IMGU driver did was that it first acquired the pointers to active and try V4L2 subdev state, and only then figured out which one to use.  The problem with that approach and a later patch (see Fixes: tag) is that as sd_state argument to v4l2_subdev_get_try_crop() et al is NULL, there is now an attempt to dereference that.  Fix this.  Also rewrap lines a little.
CVE-2022-50723: In the Linux kernel, the following vulnerability has been resolved:  bnxt_en: fix memory leak in bnxt_nvm_test()  Free the kzalloc'ed buffer before returning in the success path.
CVE-2022-50724: In the Linux kernel, the following vulnerability has been resolved:  regulator: core: fix resource leak in regulator_register()  I got some resource leak reports while doing fault injection test:    OF: ERROR: memory leak, expected refcount 1 instead of 100,   of_node_get()/of_node_put() unbalanced - destroy cset entry:   attach overlay node /i2c/pmic@64/regulators/buck1  unreferenced object 0xffff88810deea000 (size 512):   comm "490-i2c-rt5190a", pid 253, jiffies 4294859840 (age 5061.046s)   hex dump (first 32 bytes):     00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........     ff ff ff ff ff ff ff ff a0 1e 00 a1 ff ff ff ff  ................   backtrace:     [<00000000d78541e2>] kmalloc_trace+0x21/0x110     [<00000000b343d153>] device_private_init+0x32/0xd0     [<00000000be1f0c70>] device_add+0xb2d/0x1030     [<00000000e3e6344d>] regulator_register+0xaf2/0x12a0     [<00000000e2f5e754>] devm_regulator_register+0x57/0xb0     [<000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator]  unreferenced object 0xffff88810b617b80 (size 32):   comm "490-i2c-rt5190a", pid 253, jiffies 4294859904 (age 5060.983s)   hex dump (first 32 bytes):     72 65 67 75 6c 61 74 6f 72 2e 32 38 36 38 2d 53  regulator.2868-S     55 50 50 4c 59 00 ff ff 29 00 00 00 2b 00 00 00  UPPLY...)...+...   backtrace:     [<000000009da9280d>] __kmalloc_node_track_caller+0x44/0x1b0     [<0000000025c6a4e5>] kstrdup+0x3a/0x70     [<00000000790efb69>] create_regulator+0xc0/0x4e0     [<0000000005ed203a>] regulator_resolve_supply+0x2d4/0x440     [<0000000045796214>] regulator_register+0x10b3/0x12a0     [<00000000e2f5e754>] devm_regulator_register+0x57/0xb0     [<000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator]  After calling regulator_resolve_supply(), the 'rdev->supply' is set by set_supply(), after this set, in the error path, the resources need be released, so call regulator_put() to avoid the leaks.
CVE-2022-50725: In the Linux kernel, the following vulnerability has been resolved:  media: vidtv: Fix use-after-free in vidtv_bridge_dvb_init()  KASAN reports a use-after-free: BUG: KASAN: use-after-free in dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core] Call Trace:  ...  dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core]  vidtv_bridge_probe+0x7bf/0xa40 [dvb_vidtv_bridge]  platform_probe+0xb6/0x170  ... Allocated by task 1238:  ...  dvb_register_device+0x1a7/0xa70 [dvb_core]  dvb_dmxdev_init+0x2af/0x4a0 [dvb_core]  vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge]  ... Freed by task 1238:  dvb_register_device+0x6d2/0xa70 [dvb_core]  dvb_dmxdev_init+0x2af/0x4a0 [dvb_core]  vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge]  ...  It is because the error handling in vidtv_bridge_dvb_init() is wrong.  First, vidtv_bridge_dmx(dev)_init() will clean themselves when fail, but goto fail_dmx(_dev): calls release functions again, which causes use-after-free.  Also, in fail_fe, fail_tuner_probe and fail_demod_probe, j = i will cause out-of-bound when i finished its loop (i == NUM_FE). And the loop releasing is wrong, although now NUM_FE is 1 so it won't cause problem.  Fix this by correctly releasing everything.
CVE-2022-50727: In the Linux kernel, the following vulnerability has been resolved:  scsi: efct: Fix possible memleak in efct_device_init()  In efct_device_init(), when efct_scsi_reg_fc_transport() fails, efct_scsi_tgt_driver_exit() is not called to release memory for efct_scsi_tgt_driver_init() and causes memleak:  unreferenced object 0xffff8881020ce000 (size 2048):   comm "modprobe", pid 465, jiffies 4294928222 (age 55.872s)   backtrace:     [<0000000021a1ef1b>] kmalloc_trace+0x27/0x110     [<000000004c3ed51c>] target_register_template+0x4fd/0x7b0 [target_core_mod]     [<00000000f3393296>] efct_scsi_tgt_driver_init+0x18/0x50 [efct]     [<00000000115de533>] 0xffffffffc0d90011     [<00000000d608f646>] do_one_initcall+0xd0/0x4e0     [<0000000067828cf1>] do_init_module+0x1cc/0x6a0     ...
CVE-2022-50728: In the Linux kernel, the following vulnerability has been resolved:  s390/lcs: Fix return type of lcs_start_xmit()  With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals:    drivers/s390/net/lcs.c:2090:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]           .ndo_start_xmit         = lcs_start_xmit,                                     ^~~~~~~~~~~~~~   drivers/s390/net/lcs.c:2097:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]           .ndo_start_xmit         = lcs_start_xmit,                                     ^~~~~~~~~~~~~~  ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of 'netdev_tx_t', not 'int'. Adjust the return type of lcs_start_xmit() to match the prototype's to resolve the warning and potential CFI failure, should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.
CVE-2022-50729: In the Linux kernel, the following vulnerability has been resolved:  ksmbd: Fix resource leak in ksmbd_session_rpc_open()  When ksmbd_rpc_open() fails then it must call ksmbd_rpc_id_free() to undo the result of ksmbd_ipc_id_alloc().
CVE-2022-50731: In the Linux kernel, the following vulnerability has been resolved:  crypto: akcipher - default implementation for setting a private key  Changes from v1:   * removed the default implementation from set_pub_key: it is assumed that     an implementation must always have this callback defined as there are     no use case for an algorithm, which doesn't need a public key  Many akcipher implementations (like ECDSA) support only signature verifications, so they don't have all callbacks defined.  Commit 78a0324f4a53 ("crypto: akcipher - default implementations for request callbacks") introduced default callbacks for sign/verify operations, which just return an error code.  However, these are not enough, because before calling sign the caller would likely call set_priv_key first on the instantiated transform (as the in-kernel testmgr does). This function does not have a default stub, so the kernel crashes, when trying to set a private key on an akcipher, which doesn't support signature generation.  I've noticed this, when trying to add a KAT vector for ECDSA signature to the testmgr.  With this patch the testmgr returns an error in dmesg (as it should) instead of crashing the kernel NULL ptr dereference.
CVE-2022-50732: In the Linux kernel, the following vulnerability has been resolved:  staging: rtl8192u: Fix use after free in ieee80211_rx()  We cannot dereference the "skb" pointer after calling ieee80211_monitor_rx(), because it is a use after free.
CVE-2022-50733: In the Linux kernel, the following vulnerability has been resolved:  usb: idmouse: fix an uninit-value in idmouse_open  In idmouse_create_image, if any ftip_command fails, it will go to the reset label. However, this leads to the data in bulk_in_buffer[HEADER..IMGSIZE] uninitialized. And the check for valid image incurs an uninitialized dereference.  Fix this by moving the check before reset label since this check only be valid if the data after bulk_in_buffer[HEADER] has concrete data.  Note that this is found by KMSAN, so only kernel compilation is tested.
CVE-2022-50734: In the Linux kernel, the following vulnerability has been resolved:  nvmem: core: Fix memleak in nvmem_register()  dev_set_name will alloc memory for nvmem->dev.kobj.name in nvmem_register, when nvmem_validate_keepouts failed, nvmem's memory will be freed and return, but nobody will free memory for nvmem->dev.kobj.name, there will be memleak, so moving nvmem_validate_keepouts() after device_register() and let the device core deal with cleaning name in error cases.
CVE-2022-50735: In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: do not run mt76u_status_worker if the device is not running  Fix the following NULL pointer dereference avoiding to run mt76u_status_worker thread if the device is not running yet.  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 98 Comm: kworker/u2:2 Not tainted 5.14.0+ #78 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: mt76 mt76u_tx_status_data RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0 Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7 RSP: 0018:ffffc900005af988 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8 R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28 FS:  0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace:  mt76x02_send_tx_status+0x1d2/0xeb0  mt76x02_tx_status_data+0x8e/0xd0  mt76u_tx_status_data+0xe1/0x240  process_one_work+0x92b/0x1460  worker_thread+0x95/0xe00  kthread+0x3a1/0x480  ret_from_fork+0x1f/0x30 Modules linked in: --[ end trace 8df5d20fc5040f65 ]-- RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0 Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7 RSP: 0018:ffffc900005af988 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8 R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28 FS:  0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0 PKRU: 55555554  Moreover move stat_work schedule out of the for loop.
CVE-2022-50736: In the Linux kernel, the following vulnerability has been resolved:  RDMA/siw: Fix immediate work request flush to completion queue  Correctly set send queue element opcode during immediate work request flushing in post sendqueue operation, if the QP is in ERROR state. An undefined ocode value results in out-of-bounds access to an array for mapping the opcode between siw internal and RDMA core representation in work completion generation. It resulted in a KASAN BUG report of type 'global-out-of-bounds' during NFSoRDMA testing.  This patch further fixes a potential case of a malicious user which may write undefined values for completion queue elements status or opcode, if the CQ is memory mapped to user land. It avoids the same out-of-bounds access to arrays for status and opcode mapping as described above.
CVE-2022-50738: In the Linux kernel, the following vulnerability has been resolved:  vhost-vdpa: fix an iotlb memory leak  Before commit 3d5698793897 ("vhost-vdpa: introduce asid based IOTLB") we called vhost_vdpa_iotlb_unmap(v, iotlb, 0ULL, 0ULL - 1) during release to free all the resources allocated when processing user IOTLB messages through vhost_vdpa_process_iotlb_update(). That commit changed the handling of IOTLB a bit, and we accidentally removed some code called during the release.  We partially fixed this with commit 037d4305569a ("vhost-vdpa: call vhost_vdpa_cleanup during the release") but a potential memory leak is still there as showed by kmemleak if the application does not send VHOST_IOTLB_INVALIDATE or crashes:    unreferenced object 0xffff888007fbaa30 (size 16):     comm "blkio-bench", pid 914, jiffies 4294993521 (age 885.500s)     hex dump (first 16 bytes):       40 73 41 07 80 88 ff ff 00 00 00 00 00 00 00 00  @sA.............     backtrace:       [<0000000087736d2a>] kmem_cache_alloc_trace+0x142/0x1c0       [<0000000060740f50>] vhost_vdpa_process_iotlb_msg+0x68c/0x901 [vhost_vdpa]       [<0000000083e8e205>] vhost_chr_write_iter+0xc0/0x4a0 [vhost]       [<000000008f2f414a>] vhost_vdpa_chr_write_iter+0x18/0x20 [vhost_vdpa]       [<00000000de1cd4a0>] vfs_write+0x216/0x4b0       [<00000000a2850200>] ksys_write+0x71/0xf0       [<00000000de8e720b>] __x64_sys_write+0x19/0x20       [<0000000018b12cbb>] do_syscall_64+0x3f/0x90       [<00000000986ec465>] entry_SYSCALL_64_after_hwframe+0x63/0xcd  Let's fix this calling vhost_vdpa_iotlb_unmap() on the whole range in vhost_vdpa_remove_as(). We move that call before vhost_dev_cleanup() since we need a valid v->vdev.mm in vhost_vdpa_pa_unmap(). vhost_iotlb_reset() call can be removed, since vhost_vdpa_iotlb_unmap() on the whole range removes all the entries.  The kmemleak log reported was observed with a vDPA device that has `use_va` set to true (e.g. VDUSE). This patch has been tested with both types of devices.
CVE-2022-50740: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath9k: hif_usb: fix memory leak of urbs in ath9k_hif_usb_dealloc_tx_urbs()  Syzkaller reports a long-known leak of urbs in ath9k_hif_usb_dealloc_tx_urbs().  The cause of the leak is that usb_get_urb() is called but usb_free_urb() (or usb_put_urb()) is not called inside usb_kill_urb() as urb->dev or urb->ep fields have not been initialized and usb_kill_urb() returns immediately.  The patch removes trying to kill urbs located in hif_dev->tx.tx_buf because hif_dev->tx.tx_buf is not supposed to contain urbs which are in pending state (the pending urbs are stored in hif_dev->tx.tx_pending). The tx.tx_lock is acquired so there should not be any changes in the list.  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2022-50742: In the Linux kernel, the following vulnerability has been resolved:  misc: ocxl: fix possible refcount leak in afu_ioctl()  eventfd_ctx_put need to be called to put the refcount that gotten by eventfd_ctx_fdget when ocxl_irq_set_handler fails.