xamxte/cve-to-cwe huggingface dataset:
CVE-2022-50743: In the Linux kernel, the following vulnerability has been resolved:  erofs: Fix pcluster memleak when its block address is zero  syzkaller reported a memleak: https://syzkaller.appspot.com/bug?id=62f37ff612f0021641eda5b17f056f1668aa9aed  unreferenced object 0xffff88811009c7f8 (size 136):   ...   backtrace:     [<ffffffff821db19b>] z_erofs_do_read_page+0x99b/0x1740     [<ffffffff821dee9e>] z_erofs_readahead+0x24e/0x580     [<ffffffff814bc0d6>] read_pages+0x86/0x3d0     ...  syzkaller constructed a case: in z_erofs_register_pcluster(), ztailpacking = false and map->m_pa = zero. This makes pcl->obj.index be zero although pcl is not a inline pcluster.  Then following path adds refcount for grp, but the refcount won't be put because pcl is inline.  z_erofs_readahead()   z_erofs_do_read_page() # for another page     z_erofs_collector_begin()       erofs_find_workgroup()         erofs_workgroup_get()  Since it's illegal for the block address of a non-inlined pcluster to be zero, add check here to avoid registering the pcluster which would be leaked.
CVE-2022-50744: In the Linux kernel, the following vulnerability has been resolved:  scsi: lpfc: Fix hard lockup when reading the rx_monitor from debugfs  During I/O and simultaneous cat of /sys/kernel/debug/lpfc/fnX/rx_monitor, a hard lockup similar to the call trace below may occur.  The spin_lock_bh in lpfc_rx_monitor_report is not protecting from timer interrupts as expected, so change the strength of the spin lock to _irq.  Kernel panic - not syncing: Hard LOCKUP CPU: 3 PID: 110402 Comm: cat Kdump: loaded  exception RIP: native_queued_spin_lock_slowpath+91  [IRQ stack]  native_queued_spin_lock_slowpath at ffffffffb814e30b  _raw_spin_lock at ffffffffb89a667a  lpfc_rx_monitor_record at ffffffffc0a73a36 [lpfc]  lpfc_cmf_timer at ffffffffc0abbc67 [lpfc]  __hrtimer_run_queues at ffffffffb8184250  hrtimer_interrupt at ffffffffb8184ab0  smp_apic_timer_interrupt at ffffffffb8a026ba  apic_timer_interrupt at ffffffffb8a01c4f [End of IRQ stack]   apic_timer_interrupt at ffffffffb8a01c4f  lpfc_rx_monitor_report at ffffffffc0a73c80 [lpfc]  lpfc_rx_monitor_read at ffffffffc0addde1 [lpfc]  full_proxy_read at ffffffffb83e7fc3  vfs_read at ffffffffb833fe71  ksys_read at ffffffffb83402af  do_syscall_64 at ffffffffb800430b  entry_SYSCALL_64_after_hwframe at ffffffffb8a000ad
CVE-2022-50745: In the Linux kernel, the following vulnerability has been resolved:  staging: media: tegra-video: fix device_node use after free  At probe time this code path is followed:   * tegra_csi_init    * tegra_csi_channels_alloc      * for_each_child_of_node(node, channel) -- iterates over channels        * automatically gets 'channel'          * tegra_csi_channel_alloc()            * saves into chan->of_node a pointer to the channel OF node        * automatically gets and puts 'channel'        * now the node saved in chan->of_node has refcount 0, can disappear    * tegra_csi_channels_init      * iterates over channels        * tegra_csi_channel_init -- uses chan->of_node  After that, chan->of_node keeps storing the node until the device is removed.  of_node_get() the node and of_node_put() it during teardown to avoid any risk.
CVE-2022-50747: In the Linux kernel, the following vulnerability has been resolved:  hfs: Fix OOB Write in hfs_asc2mac  Syzbot reported a OOB Write bug:  loop0: detected capacity change from 0 to 64 ================================================================== BUG: KASAN: slab-out-of-bounds in hfs_asc2mac+0x467/0x9a0 fs/hfs/trans.c:133 Write of size 1 at addr ffff88801848314e by task syz-executor391/3632  Call Trace:  <TASK>  __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106  print_address_description+0x74/0x340 mm/kasan/report.c:284  print_report+0x107/0x1f0 mm/kasan/report.c:395  kasan_report+0xcd/0x100 mm/kasan/report.c:495  hfs_asc2mac+0x467/0x9a0 fs/hfs/trans.c:133  hfs_cat_build_key+0x92/0x170 fs/hfs/catalog.c:28  hfs_lookup+0x1ab/0x2c0 fs/hfs/dir.c:31  lookup_open fs/namei.c:3391 [inline]  open_last_lookups fs/namei.c:3481 [inline]  path_openat+0x10e6/0x2df0 fs/namei.c:3710  do_filp_open+0x264/0x4f0 fs/namei.c:3740  If in->len is much larger than HFS_NAMELEN(31) which is the maximum length of an HFS filename, a OOB write could occur in hfs_asc2mac(). In that case, when the dst reaches the boundary, the srclen is still greater than 0, which causes a OOB write. Fix this by adding a check on dstlen in while() before writing to dst address.
CVE-2022-50748: In the Linux kernel, the following vulnerability has been resolved:  ipc: mqueue: fix possible memory leak in init_mqueue_fs()  commit db7cfc380900 ("ipc: Free mq_sysctls if ipc namespace creation failed")  Here's a similar memory leak to the one fixed by the patch above. retire_mq_sysctls need to be called when init_mqueue_fs fails after setup_mq_sysctls.
CVE-2022-50749: In the Linux kernel, the following vulnerability has been resolved:  acct: fix potential integer overflow in encode_comp_t()  The integer overflow is descripted with following codes:   > 317 static comp_t encode_comp_t(u64 value)   > 318 {   > 319         int exp, rnd;     ......   > 341         exp <<= MANTSIZE;   > 342         exp += value;   > 343         return exp;   > 344 }  Currently comp_t is defined as type of '__u16', but the variable 'exp' is type of 'int', so overflow would happen when variable 'exp' in line 343 is greater than 65535.
CVE-2022-50750: In the Linux kernel, the following vulnerability has been resolved:  drm/panel/panel-sitronix-st7701: Remove panel on DSI attach failure  In case mipi_dsi_attach() fails, call drm_panel_remove() to avoid memory leak.
CVE-2022-50751: In the Linux kernel, the following vulnerability has been resolved:  configfs: fix possible memory leak in configfs_create_dir()  kmemleak reported memory leaks in configfs_create_dir():  unreferenced object 0xffff888009f6af00 (size 192):   comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s)   backtrace:     kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)     new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163)     configfs_register_subsystem (fs/configfs/dir.c:1857)     basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic     do_one_initcall (init/main.c:1296)     do_init_module (kernel/module/main.c:2455)     ...  unreferenced object 0xffff888003ba7180 (size 96):   comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s)   backtrace:     kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)     configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194)     configfs_make_dirent (fs/configfs/dir.c:248)     configfs_create_dir (fs/configfs/dir.c:296)     configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852)     configfs_register_subsystem (fs/configfs/dir.c:1881)     basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic     do_one_initcall (init/main.c:1296)     do_init_module (kernel/module/main.c:2455)     ...  This is because the refcount is not correct in configfs_make_dirent(). For normal stage, the refcount is changing as:  configfs_register_subsystem()   configfs_create_dir()     configfs_make_dirent()       configfs_new_dirent() # set s_count = 1       dentry->d_fsdata = configfs_get(sd); # s_count = 2 ... configfs_unregister_subsystem()   configfs_remove_dir()     remove_dir()       configfs_remove_dirent() # s_count = 1     dput() ...       *dentry_unlink_inode()*         configfs_d_iput() # s_count = 0, release  However, if we failed in configfs_create():  configfs_register_subsystem()   configfs_create_dir()     configfs_make_dirent() # s_count = 2     ...     configfs_create() # fail     ->out_remove:     configfs_remove_dirent(dentry)       configfs_put(sd) # s_count = 1       return PTR_ERR(inode);  There is no inode in the error path, so the configfs_d_iput() is lost and makes sd and fragment memory leaked.  To fix this, when we failed in configfs_create(), manually call configfs_put(sd) to keep the refcount correct.
CVE-2022-50753: In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to do sanity check on summary info  As Wenqing Liu reported in bugzilla:  https://bugzilla.kernel.org/show_bug.cgi?id=216456  BUG: KASAN: use-after-free in recover_data+0x63ae/0x6ae0 [f2fs] Read of size 4 at addr ffff8881464dcd80 by task mount/1013  CPU: 3 PID: 1013 Comm: mount Tainted: G        W          6.0.0-rc4 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Call Trace:  dump_stack_lvl+0x45/0x5e  print_report.cold+0xf3/0x68d  kasan_report+0xa8/0x130  recover_data+0x63ae/0x6ae0 [f2fs]  f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs]  f2fs_fill_super+0x4665/0x61e0 [f2fs]  mount_bdev+0x2cf/0x3b0  legacy_get_tree+0xed/0x1d0  vfs_get_tree+0x81/0x2b0  path_mount+0x47e/0x19d0  do_mount+0xce/0xf0  __x64_sys_mount+0x12c/0x1a0  do_syscall_64+0x38/0x90  entry_SYSCALL_64_after_hwframe+0x63/0xcd  The root cause is: in fuzzed image, SSA table is corrupted: ofs_in_node is larger than ADDRS_PER_PAGE(), result in out-of-range access on 4k-size page.  - recover_data  - do_recover_data   - check_index_in_prev_nodes    - f2fs_data_blkaddr  This patch adds sanity check on summary info in recovery and GC flow in where the flows rely on them.  After patch: [   29.310883] F2FS-fs (loop0): Inconsistent ofs_in_node:65286 in summary, ino:0, nid:6, max:1018
CVE-2022-50754: In the Linux kernel, the following vulnerability has been resolved:  apparmor: fix a memleak in multi_transaction_new()  In multi_transaction_new(), the variable t is not freed or passed out on the failure of copy_from_user(t->data, buf, size), which could lead to a memleak.  Fix this bug by adding a put_multi_transaction(t) in the error path.
CVE-2022-50755: In the Linux kernel, the following vulnerability has been resolved:  udf: Avoid double brelse() in udf_rename()  syzbot reported a warning like below [1]:  VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0 ... Call Trace:  <TASK>  invalidate_bh_lru+0x99/0x150  smp_call_function_many_cond+0xe2a/0x10c0  ? generic_remap_file_range_prep+0x50/0x50  ? __brelse+0xa0/0xa0  ? __mutex_lock+0x21c/0x12d0  ? smp_call_on_cpu+0x250/0x250  ? rcu_read_lock_sched_held+0xb/0x60  ? lock_release+0x587/0x810  ? __brelse+0xa0/0xa0  ? generic_remap_file_range_prep+0x50/0x50  on_each_cpu_cond_mask+0x3c/0x80  blkdev_flush_mapping+0x13a/0x2f0  blkdev_put_whole+0xd3/0xf0  blkdev_put+0x222/0x760  deactivate_locked_super+0x96/0x160  deactivate_super+0xda/0x100  cleanup_mnt+0x222/0x3d0  task_work_run+0x149/0x240  ? task_work_cancel+0x30/0x30  do_exit+0xb29/0x2a40  ? reacquire_held_locks+0x4a0/0x4a0  ? do_raw_spin_lock+0x12a/0x2b0  ? mm_update_next_owner+0x7c0/0x7c0  ? rwlock_bug.part.0+0x90/0x90  ? zap_other_threads+0x234/0x2d0  do_group_exit+0xd0/0x2a0  __x64_sys_exit_group+0x3a/0x50  do_syscall_64+0x34/0xb0  entry_SYSCALL_64_after_hwframe+0x63/0xcd  The cause of the issue is that brelse() is called on both ofibh.sbh and ofibh.ebh by udf_find_entry() when it returns NULL.  However, brelse() is called by udf_rename(), too.  So, b_count on buffer_head becomes unbalanced.  This patch fixes the issue by not calling brelse() by udf_rename() when udf_find_entry() returns NULL.
CVE-2022-50756: In the Linux kernel, the following vulnerability has been resolved:  nvme-pci: fix mempool alloc size  Convert the max size to bytes to match the units of the divisor that calculates the worst-case number of PRP entries.  The result is used to determine how many PRP Lists are required. The code was previously rounding this to 1 list, but we can require 2 in the worst case. In that scenario, the driver would corrupt memory beyond the size provided by the mempool.  While unlikely to occur (you'd need a 4MB in exactly 127 phys segments on a queue that doesn't support SGLs), this memory corruption has been observed by kfence.
CVE-2022-50758: In the Linux kernel, the following vulnerability has been resolved:  staging: vt6655: fix potential memory leak  In function device_init_td0_ring, memory is allocated for member td_info of priv->apTD0Rings[i], with i increasing from 0. In case of allocation failure, the memory is freed in reversed order, with i decreasing to 0. However, the case i=0 is left out and thus memory is leaked.  Modify the memory freeing loop to include the case i=0.
CVE-2022-50759: In the Linux kernel, the following vulnerability has been resolved:  media: i2c: ov5648: Free V4L2 fwnode data on unbind  The V4L2 fwnode data structure doesn't get freed on unbind, which leads to a memleak.
CVE-2022-50760: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: Fix PCI device refcount leak in amdgpu_atrm_get_bios()  As comment of pci_get_class() says, it returns a pci_device with its refcount increased and decreased the refcount for the input parameter @from if it is not NULL.  If we break the loop in amdgpu_atrm_get_bios() with 'pdev' not NULL, we need to call pci_dev_put() to decrease the refcount. Add the missing pci_dev_put() to avoid refcount leak.
CVE-2022-50761: In the Linux kernel, the following vulnerability has been resolved:  x86/xen: Fix memory leak in xen_init_lock_cpu()  In xen_init_lock_cpu(), the @name has allocated new string by kasprintf(), if bind_ipi_to_irqhandler() fails, it should be freed, otherwise may lead to a memory leak issue, fix it.
CVE-2022-50763: In the Linux kernel, the following vulnerability has been resolved:  crypto: marvell/octeontx - prevent integer overflows  The "code_length" value comes from the firmware file.  If your firmware is untrusted realistically there is probably very little you can do to protect yourself.  Still we try to limit the damage as much as possible. Also Smatch marks any data read from the filesystem as untrusted and prints warnings if it not capped correctly.  The "code_length * 2" can overflow.  The round_up(ucode_size, 16) + sizeof() expression can overflow too.  Prevent these overflows.
CVE-2022-50764: In the Linux kernel, the following vulnerability has been resolved:  ipv6/sit: use DEV_STATS_INC() to avoid data-races  syzbot/KCSAN reported that multiple cpus are updating dev->stats.tx_error concurrently.  This is because sit tunnels are NETIF_F_LLTX, meaning their ndo_start_xmit() is not protected by a spinlock.  While original KCSAN report was about tx path, rx path has the same issue.
CVE-2022-50765: In the Linux kernel, the following vulnerability has been resolved:  RISC-V: kexec: Fix memory leak of elf header buffer  This is reported by kmemleak detector:  unreferenced object 0xff2000000403d000 (size 4096):   comm "kexec", pid 146, jiffies 4294900633 (age 64.792s)   hex dump (first 32 bytes):     7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00  .ELF............     04 00 f3 00 01 00 00 00 00 00 00 00 00 00 00 00  ................   backtrace:     [<00000000566ca97c>] kmemleak_vmalloc+0x3c/0xbe     [<00000000979283d8>] __vmalloc_node_range+0x3ac/0x560     [<00000000b4b3712a>] __vmalloc_node+0x56/0x62     [<00000000854f75e2>] vzalloc+0x2c/0x34     [<00000000e9a00db9>] crash_prepare_elf64_headers+0x80/0x30c     [<0000000067e8bf48>] elf_kexec_load+0x3e8/0x4ec     [<0000000036548e09>] kexec_image_load_default+0x40/0x4c     [<0000000079fbe1b4>] sys_kexec_file_load+0x1c4/0x322     [<0000000040c62c03>] ret_from_syscall+0x0/0x2  In elf_kexec_load(), a buffer is allocated via vzalloc() to store elf headers.  While it's not freed back to system when kdump kernel is reloaded or unloaded, or when image->elf_header is successfully set and then fails to load kdump kernel for some reason. Fix it by freeing the buffer in arch_kimage_file_post_load_cleanup().
CVE-2022-50766: In the Linux kernel, the following vulnerability has been resolved:  btrfs: set generation before calling btrfs_clean_tree_block in btrfs_init_new_buffer  syzbot is reporting uninit-value in btrfs_clean_tree_block() [1], for commit bc877d285ca3dba2 ("btrfs: Deduplicate extent_buffer init code") missed that btrfs_set_header_generation() in btrfs_init_new_buffer() must not be moved to after clean_tree_block() because clean_tree_block() is calling btrfs_header_generation() since commit 55c69072d6bd5be1 ("Btrfs: Fix extent_buffer usage when nodesize != leafsize").  Since memzero_extent_buffer() will reset "struct btrfs_header" part, we can't move btrfs_set_header_generation() to before memzero_extent_buffer(). Just re-add btrfs_set_header_generation() before btrfs_clean_tree_block().
CVE-2022-50767: In the Linux kernel, the following vulnerability has been resolved:  fbdev: smscufx: Fix several use-after-free bugs  Several types of UAFs can occur when physically removing a USB device.  Adds ufx_ops_destroy() function to .fb_destroy of fb_ops, and in this function, there is kref_put() that finally calls ufx_free().  This fix prevents multiple UAFs.
CVE-2022-50769: In the Linux kernel, the following vulnerability has been resolved:  mmc: mxcmmc: fix return value check of mmc_add_host()  mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path.  So fix this by checking the return value and goto error path which will call mmc_free_host().
CVE-2022-50770: In the Linux kernel, the following vulnerability has been resolved:  ocfs2: fix memory leak in ocfs2_mount_volume()  There is a memory leak reported by kmemleak:    unreferenced object 0xffff88810cc65e60 (size 32):     comm "mount.ocfs2", pid 23753, jiffies 4302528942 (age 34735.105s)     hex dump (first 32 bytes):       10 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01  ................       01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00  ................     backtrace:       [<ffffffff8170f73d>] __kmalloc+0x4d/0x150       [<ffffffffa0ac3f51>] ocfs2_compute_replay_slots+0x121/0x330 [ocfs2]       [<ffffffffa0b65165>] ocfs2_check_volume+0x485/0x900 [ocfs2]       [<ffffffffa0b68129>] ocfs2_mount_volume.isra.0+0x1e9/0x650 [ocfs2]       [<ffffffffa0b7160b>] ocfs2_fill_super+0xe0b/0x1740 [ocfs2]       [<ffffffff818e1fe2>] mount_bdev+0x312/0x400       [<ffffffff819a086d>] legacy_get_tree+0xed/0x1d0       [<ffffffff818de82d>] vfs_get_tree+0x7d/0x230       [<ffffffff81957f92>] path_mount+0xd62/0x1760       [<ffffffff81958a5a>] do_mount+0xca/0xe0       [<ffffffff81958d3c>] __x64_sys_mount+0x12c/0x1a0       [<ffffffff82f26f15>] do_syscall_64+0x35/0x80       [<ffffffff8300006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0  This call stack is related to two problems.  Firstly, the ocfs2 super uses "replay_map" to trace online/offline slots, in order to recover offline slots during recovery and mount.  But when ocfs2_truncate_log_init() returns an error in ocfs2_mount_volume(), the memory of "replay_map" will not be freed in error handling path.  Secondly, the memory of "replay_map" will not be freed if d_make_root() returns an error in ocfs2_fill_super(). But the memory of "replay_map" will be freed normally when completing recovery and mount in ocfs2_complete_mount_recovery().  Fix the first problem by adding error handling path to free "replay_map" when ocfs2_truncate_log_init() fails.  And fix the second problem by calling ocfs2_free_replay_slots(osb) in the error handling path "out_dismount".  In addition, since ocfs2_free_replay_slots() is static, it is necessary to remove its static attribute and declare it in header file.
CVE-2022-50772: In the Linux kernel, the following vulnerability has been resolved:  netdevsim: fix memory leak in nsim_bus_dev_new()  If device_register() failed in nsim_bus_dev_new(), the value of reference in nsim_bus_dev->dev is 1. obj->name in nsim_bus_dev->dev will not be released.  unreferenced object 0xffff88810352c480 (size 16):   comm "echo", pid 5691, jiffies 4294945921 (age 133.270s)   hex dump (first 16 bytes):     6e 65 74 64 65 76 73 69 6d 31 00 00 00 00 00 00  netdevsim1......   backtrace:     [<000000005e2e5e26>] __kmalloc_node_track_caller+0x3a/0xb0     [<0000000094ca4fc8>] kvasprintf+0xc3/0x160     [<00000000aad09bcc>] kvasprintf_const+0x55/0x180     [<000000009bac868d>] kobject_set_name_vargs+0x56/0x150     [<000000007c1a5d70>] dev_set_name+0xbb/0xf0     [<00000000ad0d126b>] device_add+0x1f8/0x1cb0     [<00000000c222ae24>] new_device_store+0x3b6/0x5e0     [<0000000043593421>] bus_attr_store+0x72/0xa0     [<00000000cbb1833a>] sysfs_kf_write+0x106/0x160     [<00000000d0dedb8a>] kernfs_fop_write_iter+0x3a8/0x5a0     [<00000000770b66e2>] vfs_write+0x8f0/0xc80     [<0000000078bb39be>] ksys_write+0x106/0x210     [<00000000005e55a4>] do_syscall_64+0x35/0x80     [<00000000eaa40bbc>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
CVE-2022-50773: In the Linux kernel, the following vulnerability has been resolved:  ALSA: mts64: fix possible null-ptr-defer in snd_mts64_interrupt  I got a null-ptr-defer error report when I do the following tests on the qemu platform:  make defconfig and CONFIG_PARPORT=m, CONFIG_PARPORT_PC=m, CONFIG_SND_MTS64=m  Then making test scripts: cat>test_mod1.sh<<EOF modprobe snd-mts64 modprobe snd-mts64 EOF  Executing the script, perhaps several times, we will get a null-ptr-defer report, as follow:  syzkaller:~# ./test_mod.sh snd_mts64: probe of snd_mts64.0 failed with error -5 modprobe: ERROR: could not insert 'snd_mts64': No such device  BUG: kernel NULL pointer dereference, address: 0000000000000000  #PF: supervisor write access in kernel mode  #PF: error_code(0x0002) - not-present page  PGD 0 P4D 0  Oops: 0002 [#1] PREEMPT SMP PTI  CPU: 0 PID: 205 Comm: modprobe Not tainted 6.1.0-rc8-00588-g76dcd734eca2 #6  Call Trace:   <IRQ>   snd_mts64_interrupt+0x24/0xa0 [snd_mts64]   parport_irq_handler+0x37/0x50 [parport]   __handle_irq_event_percpu+0x39/0x190   handle_irq_event_percpu+0xa/0x30   handle_irq_event+0x2f/0x50   handle_edge_irq+0x99/0x1b0   __common_interrupt+0x5d/0x100   common_interrupt+0xa0/0xc0   </IRQ>   <TASK>   asm_common_interrupt+0x22/0x40  RIP: 0010:_raw_write_unlock_irqrestore+0x11/0x30   parport_claim+0xbd/0x230 [parport]   snd_mts64_probe+0x14a/0x465 [snd_mts64]   platform_probe+0x3f/0xa0   really_probe+0x129/0x2c0   __driver_probe_device+0x6d/0xc0   driver_probe_device+0x1a/0xa0   __device_attach_driver+0x7a/0xb0   bus_for_each_drv+0x62/0xb0   __device_attach+0xe4/0x180   bus_probe_device+0x82/0xa0   device_add+0x550/0x920   platform_device_add+0x106/0x220   snd_mts64_attach+0x2e/0x80 [snd_mts64]   port_check+0x14/0x20 [parport]   bus_for_each_dev+0x6e/0xc0   __parport_register_driver+0x7c/0xb0 [parport]   snd_mts64_module_init+0x31/0x1000 [snd_mts64]   do_one_initcall+0x3c/0x1f0   do_init_module+0x46/0x1c6   load_module+0x1d8d/0x1e10   __do_sys_finit_module+0xa2/0xf0   do_syscall_64+0x37/0x90   entry_SYSCALL_64_after_hwframe+0x63/0xcd   </TASK>  Kernel panic - not syncing: Fatal exception in interrupt  Rebooting in 1 seconds..  The mts wa not initialized during interrupt,  we add check for mts to fix this bug.
CVE-2022-50775: In the Linux kernel, the following vulnerability has been resolved:  RDMA/hns: Fix refcount leak in hns_roce_mmap  rdma_user_mmap_entry_get_pgoff() takes the reference. Add missing rdma_user_mmap_entry_put() to release the reference.  Acked-by Haoyue Xu <xuhaoyue1@hisilicon.com>
CVE-2022-50776: In the Linux kernel, the following vulnerability has been resolved:  clk: st: Fix memory leak in st_of_quadfs_setup()  If st_clk_register_quadfs_pll() fails, @lock should be freed before goto @err_exit, otherwise will cause meory leak issue, fix it.
CVE-2022-50777: In the Linux kernel, the following vulnerability has been resolved:  net: phy: xgmiitorgmii: Fix refcount leak in xgmiitorgmii_probe  of_phy_find_device() return device node with refcount incremented. Call put_device() to relese it when not needed anymore.