xamxte/cve-to-cwe huggingface dataset:
CVE-2022-50563: In the Linux kernel, the following vulnerability has been resolved:  dm thin: Fix UAF in run_timer_softirq()  When dm_resume() and dm_destroy() are concurrent, it will lead to UAF, as follows:   BUG: KASAN: use-after-free in __run_timers+0x173/0x710  Write of size 8 at addr ffff88816d9490f0 by task swapper/0/0 <snip>  Call Trace:   <IRQ>   dump_stack_lvl+0x73/0x9f   print_report.cold+0x132/0xaa2   _raw_spin_lock_irqsave+0xcd/0x160   __run_timers+0x173/0x710   kasan_report+0xad/0x110   __run_timers+0x173/0x710   __asan_store8+0x9c/0x140   __run_timers+0x173/0x710   call_timer_fn+0x310/0x310   pvclock_clocksource_read+0xfa/0x250   kvm_clock_read+0x2c/0x70   kvm_clock_get_cycles+0xd/0x20   ktime_get+0x5c/0x110   lapic_next_event+0x38/0x50   clockevents_program_event+0xf1/0x1e0   run_timer_softirq+0x49/0x90   __do_softirq+0x16e/0x62c   __irq_exit_rcu+0x1fa/0x270   irq_exit_rcu+0x12/0x20   sysvec_apic_timer_interrupt+0x8e/0xc0  One of the concurrency UAF can be shown as below:          use                                  free do_resume                           |   __find_device_hash_cell           |     dm_get                          |       atomic_inc(&md->holders)      |                                     | dm_destroy                                     |   __dm_destroy                                     |     if (!dm_suspended_md(md))                                     |     atomic_read(&md->holders)                                     |     msleep(1)   dm_resume                         |     __dm_resume                     |       dm_table_resume_targets       |         pool_resume                 |           do_waker  #add delay work |   dm_put                            |     atomic_dec(&md->holders)        |                                     |     dm_table_destroy                                     |       pool_dtr                                     |         __pool_dec                                     |           __pool_destroy                                     |             destroy_workqueue                                     |             kfree(pool) # free pool         time out __do_softirq   run_timer_softirq # pool has already been freed  This can be easily reproduced using:   1. create thin-pool   2. dmsetup suspend pool   3. dmsetup resume pool   4. dmsetup remove_all # Concurrent with 3  The root cause of this UAF bug is that dm_resume() adds timer after dm_destroy() skips cancelling the timer because of suspend status. After timeout, it will call run_timer_softirq(), however pool has already been freed. The concurrency UAF bug will happen.  Therefore, cancelling timer again in __pool_destroy().
CVE-2022-50565: In the Linux kernel, the following vulnerability has been resolved:  wifi: plfxlc: fix potential memory leak in __lf_x_usb_enable_rx()  urbs does not be freed in exception paths in __lf_x_usb_enable_rx(). That will trigger memory leak. To fix it, add kfree() for urbs within "error" label. Compile tested only.
CVE-2022-50566: In the Linux kernel, the following vulnerability has been resolved:  mtd: Fix device name leak when register device failed in add_mtd_device()  There is a kmemleak when register device failed:   unreferenced object 0xffff888101aab550 (size 8):     comm "insmod", pid 3922, jiffies 4295277753 (age 925.408s)     hex dump (first 8 bytes):       6d 74 64 30 00 88 ff ff                          mtd0....     backtrace:       [<00000000bde26724>] __kmalloc_node_track_caller+0x4e/0x150       [<000000003c32b416>] kvasprintf+0xb0/0x130       [<000000001f7a8f15>] kobject_set_name_vargs+0x2f/0xb0       [<000000006e781163>] dev_set_name+0xab/0xe0       [<00000000e30d0c78>] add_mtd_device+0x4bb/0x700       [<00000000f3d34de7>] mtd_device_parse_register+0x2ac/0x3f0       [<00000000c0d88488>] 0xffffffffa0238457       [<00000000b40d0922>] 0xffffffffa02a008f       [<0000000023d17b9d>] do_one_initcall+0x87/0x2a0       [<00000000770f6ca6>] do_init_module+0xdf/0x320       [<000000007b6768fe>] load_module+0x2f98/0x3330       [<00000000346bed5a>] __do_sys_finit_module+0x113/0x1b0       [<00000000674c2290>] do_syscall_64+0x35/0x80       [<000000004c6a8d97>] entry_SYSCALL_64_after_hwframe+0x46/0xb0  If register device failed, should call put_device() to give up the reference.
CVE-2022-50568: In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: f_hid: fix f_hidg lifetime vs cdev  The embedded struct cdev does not have its lifetime correctly tied to the enclosing struct f_hidg, so there is a use-after-free if /dev/hidgN is held open while the gadget is deleted.  This can readily be replicated with libusbgx's example programs (for conciseness - operating directly via configfs is equivalent):   gadget-hid  exec 3<> /dev/hidg0  gadget-vid-pid-remove  exec 3<&-  Pull the existing device up in to struct f_hidg and make use of the cdev_device_{add,del}() helpers.  This changes the lifetime of the device object to match struct f_hidg, but note that it is still added and deleted at the same time.
CVE-2022-50570: In the Linux kernel, the following vulnerability has been resolved:  platform/chrome: fix memory corruption in ioctl  If "s_mem.bytes" is larger than the buffer size it leads to memory corruption.
CVE-2022-50572: In the Linux kernel, the following vulnerability has been resolved:  ASoC: audio-graph-card: fix refcount leak of cpu_ep in __graph_for_each_link()  The of_get_next_child() returns a node with refcount incremented, and decrements the refcount of prev. So in the error path of the while loop, of_node_put() needs be called for cpu_ep.
CVE-2022-50573: In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: mt7915: fix mt7915_rate_txpower_get() resource leaks  Coverity message: variable "buf" going out of scope leaks the storage.  Addresses-Coverity-ID: 1527799 ("Resource leaks")
CVE-2022-50574: In the Linux kernel, the following vulnerability has been resolved:  drm/omap: dss: Fix refcount leak bugs  In dss_init_ports() and __dss_uninit_ports(), we should call of_node_put() for the reference returned by of_graph_get_port_by_id() in fail path or when it is not used anymore.
CVE-2022-50576: In the Linux kernel, the following vulnerability has been resolved:  serial: pch: Fix PCI device refcount leak in pch_request_dma()  As comment of pci_get_slot() says, it returns a pci_device with its refcount increased. The caller must decrement the reference count by calling pci_dev_put().  Since 'dma_dev' is only used to filter the channel in filter(), we can call pci_dev_put() before exiting from pch_request_dma(). Add the missing pci_dev_put() for the normal and error path.
CVE-2022-50577: In the Linux kernel, the following vulnerability has been resolved:  ima: Fix memory leak in __ima_inode_hash()  Commit f3cc6b25dcc5 ("ima: always measure and audit files in policy") lets measurement or audit happen even if the file digest cannot be calculated.  As a result, iint->ima_hash could have been allocated despite ima_collect_measurement() returning an error.  Since ima_hash belongs to a temporary inode metadata structure, declared at the beginning of __ima_inode_hash(), just add a kfree() call if ima_collect_measurement() returns an error different from -ENOMEM (in that case, ima_hash should not have been allocated).
CVE-2022-50578: In the Linux kernel, the following vulnerability has been resolved:  class: fix possible memory leak in __class_register()  If class_add_groups() returns error, the 'cp->subsys' need be unregister, and the 'cp' need be freed.  We can not call kset_unregister() here, because the 'cls' will be freed in callback function class_release() and it's also freed in caller's error path, it will cause double free.  So fix this by calling kobject_del() and kfree_const(name) to cleanup kobject. Besides, call kfree() to free the 'cp'.  Fault injection test can trigger this:  unreferenced object 0xffff888102fa8190 (size 8):   comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s)   hex dump (first 8 bytes):     70 6b 74 63 64 76 64 00                          pktcdvd.   backtrace:     [<00000000e7c7703d>] __kmalloc_track_caller+0x1ae/0x320     [<000000005e4d70bc>] kstrdup+0x3a/0x70     [<00000000c2e5e85a>] kstrdup_const+0x68/0x80     [<000000000049a8c7>] kvasprintf_const+0x10b/0x190     [<0000000029123163>] kobject_set_name_vargs+0x56/0x150     [<00000000747219c9>] kobject_set_name+0xab/0xe0     [<0000000005f1ea4e>] __class_register+0x15c/0x49a  unreferenced object 0xffff888037274000 (size 1024):   comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s)   hex dump (first 32 bytes):     00 40 27 37 80 88 ff ff 00 40 27 37 80 88 ff ff  .@'7.....@'7....     00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........   backtrace:     [<00000000151f9600>] kmem_cache_alloc_trace+0x17c/0x2f0     [<00000000ecf3dd95>] __class_register+0x86/0x49a
CVE-2022-50580: In the Linux kernel, the following vulnerability has been resolved:  blk-throttle: prevent overflow while calculating wait time  There is a problem found by code review in tg_with_in_bps_limit() that 'bps_limit * jiffy_elapsed_rnd' might overflow. Fix the problem by calling mul_u64_u64_div_u64() instead.
CVE-2022-50581: In the Linux kernel, the following vulnerability has been resolved:  hfs: fix OOB Read in __hfs_brec_find  Syzbot reported a OOB read bug:  ================================================================== BUG: KASAN: slab-out-of-bounds in hfs_strcmp+0x117/0x190 fs/hfs/string.c:84 Read of size 1 at addr ffff88807eb62c4e by task kworker/u4:1/11 CPU: 1 PID: 11 Comm: kworker/u4:1 Not tainted 6.1.0-rc6-syzkaller-00308-g644e9524388a #0 Workqueue: writeback wb_workfn (flush-7:0) 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_strcmp+0x117/0x190 fs/hfs/string.c:84  __hfs_brec_find+0x213/0x5c0 fs/hfs/bfind.c:75  hfs_brec_find+0x276/0x520 fs/hfs/bfind.c:138  hfs_write_inode+0x34c/0xb40 fs/hfs/inode.c:462  write_inode fs/fs-writeback.c:1440 [inline]  If the input inode of hfs_write_inode() is incorrect: struct inode   struct hfs_inode_info     struct hfs_cat_key       struct hfs_name         u8 len # len is greater than HFS_NAMELEN(31) which is the maximum length of an HFS filename  OOB read occurred: hfs_write_inode()   hfs_brec_find()     __hfs_brec_find()       hfs_cat_keycmp()         hfs_strcmp() # OOB read occurred due to len is too large  Fix this by adding a Check on len in hfs_write_inode() before calling hfs_brec_find().
CVE-2022-50582: In the Linux kernel, the following vulnerability has been resolved:  regulator: core: Prevent integer underflow  By using a ratio of delay to poll_enabled_time that is not integer time_remaining underflows and does not exit the loop as expected. As delay could be derived from DT and poll_enabled_time is defined in the driver this can easily happen.  Use a signed iterator to make sure that the loop exits once the remaining time is negative.
CVE-2023-53692: In the Linux kernel, the following vulnerability has been resolved:  ext4: fix use-after-free read in ext4_find_extent for bigalloc + inline  Syzbot found the following issue: loop0: detected capacity change from 0 to 2048 EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none. ================================================================== BUG: KASAN: use-after-free in ext4_ext_binsearch_idx fs/ext4/extents.c:768 [inline] BUG: KASAN: use-after-free in ext4_find_extent+0x76e/0xd90 fs/ext4/extents.c:931 Read of size 4 at addr ffff888073644750 by task syz-executor420/5067  CPU: 0 PID: 5067 Comm: syz-executor420 Not tainted 6.2.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace:  <TASK>  __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106  print_address_description+0x74/0x340 mm/kasan/report.c:306  print_report+0x107/0x1f0 mm/kasan/report.c:417  kasan_report+0xcd/0x100 mm/kasan/report.c:517  ext4_ext_binsearch_idx fs/ext4/extents.c:768 [inline]  ext4_find_extent+0x76e/0xd90 fs/ext4/extents.c:931  ext4_clu_mapped+0x117/0x970 fs/ext4/extents.c:5809  ext4_insert_delayed_block fs/ext4/inode.c:1696 [inline]  ext4_da_map_blocks fs/ext4/inode.c:1806 [inline]  ext4_da_get_block_prep+0x9e8/0x13c0 fs/ext4/inode.c:1870  ext4_block_write_begin+0x6a8/0x2290 fs/ext4/inode.c:1098  ext4_da_write_begin+0x539/0x760 fs/ext4/inode.c:3082  generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772  ext4_buffered_write_iter+0x122/0x3a0 fs/ext4/file.c:285  ext4_file_write_iter+0x1d0/0x18f0  call_write_iter include/linux/fs.h:2186 [inline]  new_sync_write fs/read_write.c:491 [inline]  vfs_write+0x7dc/0xc50 fs/read_write.c:584  ksys_write+0x177/0x2a0 fs/read_write.c:637  do_syscall_x64 arch/x86/entry/common.c:50 [inline]  do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80  entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f4b7a9737b9 RSP: 002b:00007ffc5cac3668 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4b7a9737b9 RDX: 00000000175d9003 RSI: 0000000020000200 RDI: 0000000000000004 RBP: 00007f4b7a933050 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000079f R11: 0000000000000246 R12: 00007f4b7a9330e0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000  </TASK>  Above issue is happens when enable bigalloc and inline data feature. As commit 131294c35ed6 fixed delayed allocation bug in ext4_clu_mapped for bigalloc + inline. But it only resolved issue when has inline data, if inline data has been converted to extent(ext4_da_convert_inline_data_to_extent) before writepages, there is no EXT4_STATE_MAY_INLINE_DATA flag. However i_data is still store inline data in this scene. Then will trigger UAF when find extent. To resolve above issue, there is need to add judge "ext4_has_inline_data(inode)" in ext4_clu_mapped().
CVE-2023-53693: In the Linux kernel, the following vulnerability has been resolved:  USB: gadget: Fix the memory leak in raw_gadget driver  Currently, increasing raw_dev->count happens before invoke the raw_queue_event(), if the raw_queue_event() return error, invoke raw_release() will not trigger the dev_free() to be called.  [  268.905865][ T5067] raw-gadget.0 gadget.0: failed to queue event [  268.912053][ T5067] udc dummy_udc.0: failed to start USB Raw Gadget: -12 [  268.918885][ T5067] raw-gadget.0: probe of gadget.0 failed with error -12 [  268.925956][ T5067] UDC core: USB Raw Gadget: couldn't find an available UDC or it's busy [  268.934657][ T5067] misc raw-gadget: fail, usb_gadget_register_driver returned -16  BUG: memory leak  [<ffffffff8154bf94>] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076 [<ffffffff8347eb55>] kmalloc include/linux/slab.h:582 [inline] [<ffffffff8347eb55>] kzalloc include/linux/slab.h:703 [inline] [<ffffffff8347eb55>] dev_new drivers/usb/gadget/legacy/raw_gadget.c:191 [inline] [<ffffffff8347eb55>] raw_open+0x45/0x110 drivers/usb/gadget/legacy/raw_gadget.c:385 [<ffffffff827d1d09>] misc_open+0x1a9/0x1f0 drivers/char/misc.c:165  [<ffffffff8154bf94>] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076 [<ffffffff8347cd2f>] kmalloc include/linux/slab.h:582 [inline] [<ffffffff8347cd2f>] raw_ioctl_init+0xdf/0x410 drivers/usb/gadget/legacy/raw_gadget.c:460 [<ffffffff8347dfe9>] raw_ioctl+0x5f9/0x1120 drivers/usb/gadget/legacy/raw_gadget.c:1250 [<ffffffff81685173>] vfs_ioctl fs/ioctl.c:51 [inline]  [<ffffffff8154bf94>] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076 [<ffffffff833ecc6a>] kmalloc include/linux/slab.h:582 [inline] [<ffffffff833ecc6a>] kzalloc include/linux/slab.h:703 [inline] [<ffffffff833ecc6a>] dummy_alloc_request+0x5a/0xe0 drivers/usb/gadget/udc/dummy_hcd.c:665 [<ffffffff833e9132>] usb_ep_alloc_request+0x22/0xd0 drivers/usb/gadget/udc/core.c:196 [<ffffffff8347f13d>] gadget_bind+0x6d/0x370 drivers/usb/gadget/legacy/raw_gadget.c:292  This commit therefore invoke kref_get() under the condition that raw_queue_event() return success.
CVE-2023-53694: In the Linux kernel, the following vulnerability has been resolved:  riscv: ftrace: Fixup panic by disabling preemption  In RISCV, we must use an AUIPC + JALR pair to encode an immediate, forming a jump that jumps to an address over 4K. This may cause errors if we want to enable kernel preemption and remove dependency from patching code with stop_machine(). For example, if a task was switched out on auipc. And, if we changed the ftrace function before it was switched back, then it would jump to an address that has updated 11:0 bits mixing with previous XLEN:12 part.  p: patched area performed by dynamic ftrace ftrace_prologue: p|      REG_S   ra, -SZREG(sp) p|      auipc   ra, 0x? ------------> preempted      ...     change ftrace function      ... p|      jalr    -?(ra) <------------- switched back p|      REG_L   ra, -SZREG(sp) func:  xxx  ret
CVE-2023-53696: In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Fix memory leak in qla2x00_probe_one()  There is a memory leak reported by kmemleak:    unreferenced object 0xffffc900003f0000 (size 12288):     comm "modprobe", pid 19117, jiffies 4299751452 (age 42490.264s)     hex dump (first 32 bytes):       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................     backtrace:       [<00000000629261a8>] __vmalloc_node_range+0xe56/0x1110       [<0000000001906886>] __vmalloc_node+0xbd/0x150       [<000000005bb4dc34>] vmalloc+0x25/0x30       [<00000000a2dc1194>] qla2x00_create_host+0x7a0/0xe30 [qla2xxx]       [<0000000062b14b47>] qla2x00_probe_one+0x2eb8/0xd160 [qla2xxx]       [<00000000641ccc04>] local_pci_probe+0xeb/0x1a0  The root cause is traced to an error-handling path in qla2x00_probe_one() when the adapter "base_vha" initialize failed. The fab_scan_rp "scan.l" is used to record the port information and it is allocated in qla2x00_create_host(). However, it is not released in the error handling path "probe_failed".  Fix this by freeing the memory of "scan.l" when an error occurs in the adapter initialization process.
CVE-2023-53697: In the Linux kernel, the following vulnerability has been resolved:  nvdimm: Fix memleak of pmu attr_groups in unregister_nvdimm_pmu()  Memory pointed by 'nd_pmu->pmu.attr_groups' is allocated in function 'register_nvdimm_pmu' and is lost after 'kfree(nd_pmu)' call in function 'unregister_nvdimm_pmu'.
CVE-2023-53700: In the Linux kernel, the following vulnerability has been resolved:  media: max9286: Fix memleak in max9286_v4l2_register()  There is a kmemleak when testing the media/i2c/max9286.c with bpf mock device:  kmemleak: 5 new suspected memory leaks (see /sys/kernel/debug/kmemleak)  unreferenced object 0xffff88810defc400 (size 256):   comm "python3", pid 278, jiffies 4294737563 (age 31.978s)   hex dump (first 32 bytes):     28 06 a7 0a 81 88 ff ff 00 fe 22 12 81 88 ff ff  (.........".....     10 c4 ef 0d 81 88 ff ff 10 c4 ef 0d 81 88 ff ff  ................   backtrace:     [<00000000191de6a7>] __kmalloc_node+0x44/0x1b0     [<000000002f4912b7>] kvmalloc_node+0x34/0x180     [<0000000057dc4cae>] v4l2_ctrl_new+0x325/0x10f0 [videodev]     [<0000000026030272>] v4l2_ctrl_new_std+0x16f/0x210 [videodev]     [<00000000f0d9ea2f>] max9286_probe+0x76e/0xbff [max9286]     [<00000000ea8f6455>] i2c_device_probe+0x28d/0x680     [<0000000087529af3>] really_probe+0x17c/0x3f0     [<00000000b08be526>] __driver_probe_device+0xe3/0x170     [<000000004382edea>] driver_probe_device+0x49/0x120     [<000000007bde528a>] __device_attach_driver+0xf7/0x150     [<000000009f9c6ab4>] bus_for_each_drv+0x114/0x180     [<00000000c8aaf588>] __device_attach+0x1e5/0x2d0     [<0000000041cc06b9>] bus_probe_device+0x126/0x140     [<000000002309860d>] device_add+0x810/0x1130     [<000000002827bf98>] i2c_new_client_device+0x359/0x4f0     [<00000000593bdc85>] of_i2c_register_device+0xf1/0x110  max9286_v4l2_register() calls v4l2_ctrl_new_std(), but won't free the created v412_ctrl when fwnode_graph_get_endpoint_by_id() failed, which causes the memleak. Call v4l2_ctrl_handler_free() to free the v412_ctrl.
CVE-2023-53702: In the Linux kernel, the following vulnerability has been resolved:  s390/crypto: use vector instructions only if available for ChaCha20  Commit 349d03ffd5f6 ("crypto: s390 - add crypto library interface for ChaCha20") added a library interface to the s390 specific ChaCha20 implementation. However no check was added to verify if the required facilities are installed before branching into the assembler code.  If compiled into the kernel, this will lead to the following crash, if vector instructions are not available:  data exception: 0007 ilc:3 [#1] SMP Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7+ #11 Hardware name: IBM 3931 A01 704 (KVM/Linux) Krnl PSW : 0704e00180000000 000000001857277a (chacha20_vx+0x32/0x818)            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000037f0000000a ffffffffffffff60 000000008184b000 0000000019f5c8e6            0000000000000109 0000037fffb13c58 0000037fffb13c78 0000000019bb1780            0000037fffb13c58 0000000019f5c8e6 000000008184b000 0000000000000109            00000000802d8000 0000000000000109 0000000018571ebc 0000037fffb13718 Krnl Code: 000000001857276a: c07000b1f80b        larl    %r7,0000000019bb1780            0000000018572770: a708000a            lhi     %r0,10           #0000000018572774: e78950000c36        vlm     %v24,%v25,0(%r5),0           >000000001857277a: e7a060000806        vl      %v26,0(%r6),0            0000000018572780: e7bf70004c36        vlm     %v27,%v31,0(%r7),4            0000000018572786: e70b00000456        vlr     %v0,%v27            000000001857278c: e71800000456        vlr     %v1,%v24            0000000018572792: e74b00000456        vlr     %v4,%v27 Call Trace:  [<000000001857277a>] chacha20_vx+0x32/0x818 Last Breaking-Event-Address:  [<0000000018571eb6>] chacha20_crypt_s390.constprop.0+0x6e/0xd8 ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b  Fix this by adding a missing MACHINE_HAS_VX check.  [agordeev@linux.ibm.com: remove duplicates in commit message]
CVE-2023-53704: In the Linux kernel, the following vulnerability has been resolved:  clk: imx: clk-imx8mp: improve error handling in imx8mp_clocks_probe()  Replace of_iomap() and kzalloc() with devm_of_iomap() and devm_kzalloc() which can automatically release the related memory when the device or driver is removed or unloaded to avoid potential memory leak.  In this case, iounmap(anatop_base) in line 427,433 are removed as manual release is not required.  Besides, referring to clk-imx8mq.c, check the return code of of_clk_add_hw_provider, if it returns negtive, print error info and unregister hws, which makes the program more robust.
CVE-2023-53705: In the Linux kernel, the following vulnerability has been resolved:  ipv6: Fix out-of-bounds access in ipv6_find_tlv()  optlen is fetched without checking whether there is more than one byte to parse. It can lead to out-of-bounds access.  Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2023-53707: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1  The type of size is unsigned int, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later.
CVE-2023-53708: In the Linux kernel, the following vulnerability has been resolved:  ACPI: x86: s2idle: Catch multiple ACPI_TYPE_PACKAGE objects  If a badly constructed firmware includes multiple `ACPI_TYPE_PACKAGE` objects while evaluating the AMD LPS0 _DSM, there will be a memory leak.  Explicitly guard against this.