{"schema_version":"1.7.2","id":"OESA-2025-1820","modified":"2025-07-11T12:24:58Z","published":"2025-07-11T12:24:58Z","upstream":["CVE-2022-49862","CVE-2022-49871","CVE-2022-49881","CVE-2022-49907","CVE-2022-49918","CVE-2022-49921","CVE-2022-49934","CVE-2022-49938","CVE-2022-49942","CVE-2022-49948","CVE-2022-49964","CVE-2022-49969","CVE-2022-49986","CVE-2022-49987","CVE-2022-49989","CVE-2022-50022","CVE-2022-50033","CVE-2022-50053","CVE-2022-50066","CVE-2022-50084","CVE-2022-50085","CVE-2022-50087","CVE-2022-50098","CVE-2022-50103","CVE-2022-50127","CVE-2022-50134","CVE-2022-50160","CVE-2022-50185","CVE-2022-50191","CVE-2022-50202","CVE-2022-50211","CVE-2022-50220","CVE-2022-50228","CVE-2022-50229","CVE-2023-3090","CVE-2023-53109","CVE-2025-37911","CVE-2025-37932","CVE-2025-38023","CVE-2025-38024","CVE-2025-38063","CVE-2025-38079"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix the msg-\u0026gt;req tlv len check in tipc_nl_compat_name_table_dump_header\n\nThis is a follow-up for commit 974cb0e3e7c9 (\u0026quot;tipc: fix uninit-value\nin tipc_nl_compat_name_table_dump\u0026quot;) where it should have type casted\nsizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negative\nvalue.\n\nsyzbot reported a call trace because of it:\n\n  BUG: KMSAN: uninit-value in ...\n   tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934\n   __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238\n   tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321\n   tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324\n   genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]\n   genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]\n   genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792\n   netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501\n   genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803\n   netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n   netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345\n   netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921\n   sock_sendmsg_nosec net/socket.c:714 [inline]\n   sock_sendmsg net/socket.c:734 [inline](CVE-2022-49862)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: tun: Fix memory leaks of napi_get_frags\n\nkmemleak reports after running test_progs:\n\nunreferenced object 0xffff8881b1672dc0 (size 232):\n  comm \u0026quot;test_progs\u0026quot;, pid 394388, jiffies 4354712116 (age 841.975s)\n  hex dump (first 32 bytes):\n    e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff  .........,g.....\n    00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00  .@..............\n  backtrace:\n    [\u0026lt;00000000c8f01748\u0026gt;] napi_skb_cache_get+0xd4/0x150\n    [\u0026lt;0000000041c7fc09\u0026gt;] __napi_build_skb+0x15/0x50\n    [\u0026lt;00000000431c7079\u0026gt;] __napi_alloc_skb+0x26e/0x540\n    [\u0026lt;000000003ecfa30e\u0026gt;] napi_get_frags+0x59/0x140\n    [\u0026lt;0000000099b2199e\u0026gt;] tun_get_user+0x183d/0x3bb0 [tun]\n    [\u0026lt;000000008a5adef0\u0026gt;] tun_chr_write_iter+0xc0/0x1b1 [tun]\n    [\u0026lt;0000000049993ff4\u0026gt;] do_iter_readv_writev+0x19f/0x320\n    [\u0026lt;000000008f338ea2\u0026gt;] do_iter_write+0x135/0x630\n    [\u0026lt;000000008a3377a4\u0026gt;] vfs_writev+0x12e/0x440\n    [\u0026lt;00000000a6b5639a\u0026gt;] do_writev+0x104/0x280\n    [\u0026lt;00000000ccf065d8\u0026gt;] do_syscall_64+0x3b/0x90\n    [\u0026lt;00000000d776e329\u0026gt;] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe issue occurs in the following scenarios:\ntun_get_user()\n  napi_gro_frags()\n    napi_frags_finish()\n      case GRO_NORMAL:\n        gro_normal_one()\n          list_add_tail(\u0026amp;skb-\u0026gt;list, \u0026amp;napi-\u0026gt;rx_list);\n          \u0026lt;-- While napi-\u0026gt;rx_count \u0026lt; READ_ONCE(gro_normal_batch),\n          \u0026lt;-- gro_normal_list() is not called, napi-\u0026gt;rx_list is not empty\n  \u0026lt;-- not ask to complete the gro work, will cause memory leaks in\n  \u0026lt;-- following tun_napi_del()\n...\ntun_napi_del()\n  netif_napi_del()\n    __netif_napi_del()\n    \u0026lt;-- \u0026amp;napi-\u0026gt;rx_list is not empty, which caused memory leaks\n\nTo fix, add napi_complete() after napi_gro_frags().(CVE-2022-49871)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: fix memory leak in query_regdb_file()\n\nIn the function query_regdb_file() the alpha2 parameter is duplicated\nusing kmemdup() and subsequently freed in regdb_fw_cb(). However,\nrequest_firmware_nowait() can fail without calling regdb_fw_cb() and\nthus leak memory.(CVE-2022-49881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: mdio: fix undefined behavior in bit shift for __mdiobus_register\n\nShifting signed 32-bit value by 31 bits is undefined, so changing\nsignificant bit to unsigned. The UBSAN warning calltrace like below:\n\nUBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27\nleft shift of 1 by 31 places cannot be represented in type \u0026apos;int\u0026apos;\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x7d/0xa5\n dump_stack+0x15/0x1b\n ubsan_epilogue+0xe/0x4e\n __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c\n __mdiobus_register+0x49d/0x4e0\n fixed_mdio_bus_init+0xd8/0x12d\n do_one_initcall+0x76/0x430\n kernel_init_freeable+0x3b3/0x422\n kernel_init+0x24/0x1e0\n ret_from_fork+0x1f/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2022-49907)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix WARNING in __ip_vs_cleanup_batch()\n\nDuring the initialization of ip_vs_conn_net_init(), if file ip_vs_conn\nor ip_vs_conn_sync fails to be created, the initialization is successful\nby default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn\u0026apos;t\nbe found during the remove.\n\nThe following is the stack information:\nname \u0026apos;ip_vs_conn_sync\u0026apos;\nWARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712\nremove_proc_entry+0x389/0x460\nModules linked in:\nWorkqueue: netns cleanup_net\nRIP: 0010:remove_proc_entry+0x389/0x460\nCall Trace:\n\u0026lt;TASK\u0026gt;\n__ip_vs_cleanup_batch+0x7d/0x120\nops_exit_list+0x125/0x170\ncleanup_net+0x4ea/0xb00\nprocess_one_work+0x9bf/0x1710\nworker_thread+0x665/0x1080\nkthread+0x2e4/0x3a0\nret_from_fork+0x1f/0x30\n\u0026lt;/TASK\u0026gt;(CVE-2022-49918)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: Fix use after free in red_enqueue()\n\nWe can\u0026apos;t use \u0026quot;skb\u0026quot; again after passing it to qdisc_enqueue().  This is\nbasically identical to commit 2f09707d0c97 (\u0026quot;sch_sfb: Also store skb\nlen before calling child enqueue\u0026quot;).(CVE-2022-49921)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Fix UAF in ieee80211_scan_rx()\n\nieee80211_scan_rx() tries to access scan_req-\u0026gt;flags after a\nnull check, but a UAF is observed when the scan is completed\nand __ieee80211_scan_completed() executes, which then calls\ncfg80211_scan_done() leading to the freeing of scan_req.\n\nSince scan_req is rcu_dereference()\u0026apos;d, prevent the racing in\n__ieee80211_scan_completed() by ensuring that from mac80211\u0026apos;s\nPOV it is no longer accessed from an RCU read critical section\nbefore we call cfg80211_scan_done().(CVE-2022-49934)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix small mempool leak in SMB2_negotiate()\n\nIn some cases of failure (dialect mismatches) in SMB2_negotiate(), after\nthe request is sent, the checks would return -EIO when they should be\nrather setting rc = -EIO and jumping to neg_exit to free the response\nbuffer from mempool.(CVE-2022-49938)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Don\u0026apos;t finalize CSA in IBSS mode if state is disconnected\n\nWhen we are not connected to a channel, sending channel \u0026quot;switch\u0026quot;\nannouncement doesn\u0026apos;t make any sense.\n\nThe BSS list is empty in that case. This causes the for loop in\ncfg80211_get_bss() to be bypassed, so the function returns NULL\n(check line 1424 of net/wireless/scan.c), causing the WARN_ON()\nin ieee80211_ibss_csa_beacon() to get triggered (check line 500\nof net/mac80211/ibss.c), which was consequently reported on the\nsyzkaller dashboard.\n\nThus, check if we have an existing connection before generating\nthe CSA beacon in ieee80211_ibss_finish_csa().(CVE-2022-49942)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvt: Clear selection before changing the font\n\nWhen changing the console font with ioctl(KDFONTOP) the new font size\ncan be bigger than the previous font. A previous selection may thus now\nbe outside of the new screen size and thus trigger out-of-bounds\naccesses to graphics memory if the selection is removed in\nvc_do_resize().\n\nPrevent such out-of-memory accesses by dropping the selection before the\nvarious con_font_set() console handlers are called.(CVE-2022-49948)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: cacheinfo: Fix incorrect assignment of signed error value to unsigned fw_level\n\nThough acpi_find_last_cache_level() always returned signed value and the\ndocument states it will return any errors caused by lack of a PPTT table,\nit never returned negative values before.\n\nCommit 0c80f9e165f8 (\u0026quot;ACPI: PPTT: Leave the table mapped for the runtime usage\u0026quot;)\nhowever changed it by returning -ENOENT if no PPTT was found. The value\nreturned from acpi_find_last_cache_level() is then assigned to unsigned\nfw_level.\n\nIt will result in the number of cache leaves calculated incorrectly as\na huge value which will then cause the following warning from __alloc_pages\nas the order would be great than MAX_ORDER because of incorrect and huge\ncache leaves value.\n\n  |  WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:5407 __alloc_pages+0x74/0x314\n  |  Modules linked in:\n  |  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-10393-g7c2a8d3ac4c0 #73\n  |  pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  |  pc : __alloc_pages+0x74/0x314\n  |  lr : alloc_pages+0xe8/0x318\n  |  Call trace:\n  |   __alloc_pages+0x74/0x314\n  |   alloc_pages+0xe8/0x318\n  |   kmalloc_order_trace+0x68/0x1dc\n  |   __kmalloc+0x240/0x338\n  |   detect_cache_attributes+0xe0/0x56c\n  |   update_siblings_masks+0x38/0x284\n  |   store_cpu_topology+0x78/0x84\n  |   smp_prepare_cpus+0x48/0x134\n  |   kernel_init_freeable+0xc4/0x14c\n  |   kernel_init+0x2c/0x1b4\n  |   ret_from_fork+0x10/0x20\n\nFix the same by changing fw_level to be signed integer and return the\nerror from init_cache_level() early in case of error.(CVE-2022-49964)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: clear optc underflow before turn off odm clock\n\n[Why]\nAfter ODM clock off, optc underflow bit will be kept there always and clear not work.\nWe need to clear that before clock off.\n\n[How]\nClear that if have when clock off.(CVE-2022-49969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq\n\nstorvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it\ndoesn\u0026apos;t need to make forward progress under memory pressure.  Marking this\nworkqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a\nnon-WQ_MEM_RECLAIM workqueue.  In the current state it causes the following\nwarning:\n\n[   14.506347] ------------[ cut here ]------------\n[   14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn\n[   14.506360] WARNING: CPU: 0 PID: 8 at \u0026lt;-snip-\u0026gt;kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130\n[   14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu\n[   14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022\n[   14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun\n[   14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130\n\t\t\u0026lt;-snip-\u0026gt;\n[   14.506408] Call Trace:\n[   14.506412]  __flush_work+0xf1/0x1c0\n[   14.506414]  __cancel_work_timer+0x12f/0x1b0\n[   14.506417]  ? kernfs_put+0xf0/0x190\n[   14.506418]  cancel_delayed_work_sync+0x13/0x20\n[   14.506420]  disk_block_events+0x78/0x80\n[   14.506421]  del_gendisk+0x3d/0x2f0\n[   14.506423]  sr_remove+0x28/0x70\n[   14.506427]  device_release_driver_internal+0xef/0x1c0\n[   14.506428]  device_release_driver+0x12/0x20\n[   14.506429]  bus_remove_device+0xe1/0x150\n[   14.506431]  device_del+0x167/0x380\n[   14.506432]  __scsi_remove_device+0x11d/0x150\n[   14.506433]  scsi_remove_device+0x26/0x40\n[   14.506434]  storvsc_remove_lun+0x40/0x60\n[   14.506436]  process_one_work+0x209/0x400\n[   14.506437]  worker_thread+0x34/0x400\n[   14.506439]  kthread+0x121/0x140\n[   14.506440]  ? process_one_work+0x400/0x400\n[   14.506441]  ? kthread_park+0x90/0x90\n[   14.506443]  ret_from_fork+0x35/0x40\n[   14.506445] ---[ end trace 2d9633159fdc6ee7 ]---(CVE-2022-49986)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: call __md_stop_writes in md_stop\n\nFrom the link [1], we can see raid1d was running even after the path\nraid_dtr -\u0026gt; md_stop -\u0026gt; __md_stop.\n\nLet\u0026apos;s stop write first in destructor to align with normal md-raid to\nfix the KASAN issue.\n\n[1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a(CVE-2022-49987)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen/privcmd: fix error exit of privcmd_ioctl_dm_op()\n\nThe error exit of privcmd_ioctl_dm_op() is calling unlock_pages()\npotentially with pages being NULL, leading to a NULL dereference.\n\nAdditionally lock_pages() doesn\u0026apos;t check for pin_user_pages_fast()\nhaving been completely successful, resulting in potentially not\nlocking all pages into memory. This could result in sporadic failures\nwhen using the related memory in user mode.\n\nFix all of that by calling unlock_pages() always with the real number\nof pinned pages, which will be zero in case pages being NULL, and by\nchecking the number of pages pinned by pin_user_pages_fast() matching\nthe expected number of pages.(CVE-2022-49989)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers:md:fix a potential use-after-free bug\n\nIn line 2884, \u0026quot;raid5_release_stripe(sh);\u0026quot; drops the reference to sh and\nmay cause sh to be released. However, sh is subsequently used in lines\n2886 \u0026quot;if (sh-\u0026gt;batch_head \u0026amp;\u0026amp; sh != sh-\u0026gt;batch_head)\u0026quot;. This may result in an\nuse-after-free bug.\n\nIt can be fixed by moving \u0026quot;raid5_release_stripe(sh);\u0026quot; to the bottom of\nthe function.(CVE-2022-50022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: host: ohci-ppc-of: Fix refcount leak bug\n\nIn ohci_hcd_ppc_of_probe(), of_find_compatible_node() will return\na node pointer with refcount incremented. We should use of_node_put()\nwhen it is not used anymore.(CVE-2022-50033)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niavf: Fix reset error handling\n\nDo not call iavf_close in iavf_reset_task error handling. Doing so can\nlead to double call of napi_disable, which can lead to deadlock there.\nRemoving VF would lead to iavf_remove task being stuck, because it\nrequires crit_lock, which is held by iavf_close.\nCall iavf_disable_vf if reset fail, so that driver will clean up\nremaining invalid resources.\nDuring rapid VF resets, HW can fail to setup VF mailbox. Wrong\nerror handling can lead to iavf_remove being stuck with:\n[ 5218.999087] iavf 0000:82:01.0: Failed to init adminq: -53\n...\n[ 5267.189211] INFO: task repro.sh:11219 blocked for more than 30 seconds.\n[ 5267.189520]       Tainted: G S          E     5.18.0-04958-ga54ce3703613-dirty #1\n[ 5267.189764] \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n[ 5267.190062] task:repro.sh        state:D stack:    0 pid:11219 ppid:  8162 flags:0x00000000\n[ 5267.190347] Call Trace:\n[ 5267.190647]  \u0026lt;TASK\u0026gt;\n[ 5267.190927]  __schedule+0x460/0x9f0\n[ 5267.191264]  schedule+0x44/0xb0\n[ 5267.191563]  schedule_preempt_disabled+0x14/0x20\n[ 5267.191890]  __mutex_lock.isra.12+0x6e3/0xac0\n[ 5267.192237]  ? iavf_remove+0xf9/0x6c0 [iavf]\n[ 5267.192565]  iavf_remove+0x12a/0x6c0 [iavf]\n[ 5267.192911]  ? _raw_spin_unlock_irqrestore+0x1e/0x40\n[ 5267.193285]  pci_device_remove+0x36/0xb0\n[ 5267.193619]  device_release_driver_internal+0xc1/0x150\n[ 5267.193974]  pci_stop_bus_device+0x69/0x90\n[ 5267.194361]  pci_stop_and_remove_bus_device+0xe/0x20\n[ 5267.194735]  pci_iov_remove_virtfn+0xba/0x120\n[ 5267.195130]  sriov_disable+0x2f/0xe0\n[ 5267.195506]  ice_free_vfs+0x7d/0x2f0 [ice]\n[ 5267.196056]  ? pci_get_device+0x4f/0x70\n[ 5267.196496]  ice_sriov_configure+0x78/0x1a0 [ice]\n[ 5267.196995]  sriov_numvfs_store+0xfe/0x140\n[ 5267.197466]  kernfs_fop_write_iter+0x12e/0x1c0\n[ 5267.197918]  new_sync_write+0x10c/0x190\n[ 5267.198404]  vfs_write+0x24e/0x2d0\n[ 5267.198886]  ksys_write+0x5c/0xd0\n[ 5267.199367]  do_syscall_64+0x3a/0x80\n[ 5267.199827]  entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[ 5267.200317] RIP: 0033:0x7f5b381205c8\n[ 5267.200814] RSP: 002b:00007fff8c7e8c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[ 5267.201981] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f5b381205c8\n[ 5267.202620] RDX: 0000000000000002 RSI: 00005569420ee900 RDI: 0000000000000001\n[ 5267.203426] RBP: 00005569420ee900 R08: 000000000000000a R09: 00007f5b38180820\n[ 5267.204327] R10: 000000000000000a R11: 0000000000000246 R12: 00007f5b383c06e0\n[ 5267.205193] R13: 0000000000000002 R14: 00007f5b383bb880 R15: 0000000000000002\n[ 5267.206041]  \u0026lt;/TASK\u0026gt;\n[ 5267.206970] Kernel panic - not syncing: hung_task: blocked tasks\n[ 5267.207809] CPU: 48 PID: 551 Comm: khungtaskd Kdump: loaded Tainted: G S          E     5.18.0-04958-ga54ce3703613-dirty #1\n[ 5267.208726] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 11/02/2019\n[ 5267.209623] Call Trace:\n[ 5267.210569]  \u0026lt;TASK\u0026gt;\n[ 5267.211480]  dump_stack_lvl+0x33/0x42\n[ 5267.212472]  panic+0x107/0x294\n[ 5267.213467]  watchdog.cold.8+0xc/0xbb\n[ 5267.214413]  ? proc_dohung_task_timeout_secs+0x30/0x30\n[ 5267.215511]  kthread+0xf4/0x120\n[ 5267.216459]  ? kthread_complete_and_exit+0x20/0x20\n[ 5267.217505]  ret_from_fork+0x22/0x30\n[ 5267.218459]  \u0026lt;/TASK\u0026gt;(CVE-2022-50053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: atlantic: fix aq_vec index out of range error\n\nThe final update statement of the for loop exceeds the array range, the\ndereference of self-\u0026gt;aq_vec[i] is not checked and then leads to the\nindex out of range error.\nAlso fixed this kind of coding style in other for loop.\n\n[   97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48\n[   97.937607] index 8 is out of range for type \u0026apos;aq_vec_s *[8]\u0026apos;\n[   97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2\n[   97.937610] Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022\n[   97.937611] Workqueue: events_unbound async_run_entry_fn\n[   97.937616] Call Trace:\n[   97.937617]  \u0026lt;TASK\u0026gt;\n[   97.937619]  dump_stack_lvl+0x49/0x63\n[   97.937624]  dump_stack+0x10/0x16\n[   97.937626]  ubsan_epilogue+0x9/0x3f\n[   97.937627]  __ubsan_handle_out_of_bounds.cold+0x44/0x49\n[   97.937629]  ? __scm_send+0x348/0x440\n[   97.937632]  ? aq_vec_stop+0x72/0x80 [atlantic]\n[   97.937639]  aq_nic_stop+0x1b6/0x1c0 [atlantic]\n[   97.937644]  aq_suspend_common+0x88/0x90 [atlantic]\n[   97.937648]  aq_pm_suspend_poweroff+0xe/0x20 [atlantic]\n[   97.937653]  pci_pm_suspend+0x7e/0x1a0\n[   97.937655]  ? pci_pm_suspend_noirq+0x2b0/0x2b0\n[   97.937657]  dpm_run_callback+0x54/0x190\n[   97.937660]  __device_suspend+0x14c/0x4d0\n[   97.937661]  async_suspend+0x23/0x70\n[   97.937663]  async_run_entry_fn+0x33/0x120\n[   97.937664]  process_one_work+0x21f/0x3f0\n[   97.937666]  worker_thread+0x4a/0x3c0\n[   97.937668]  ? process_one_work+0x3f0/0x3f0\n[   97.937669]  kthread+0xf0/0x120\n[   97.937671]  ? kthread_complete_and_exit+0x20/0x20\n[   97.937672]  ret_from_fork+0x22/0x30\n[   97.937676]  \u0026lt;/TASK\u0026gt;\n\nv2. fixed \u0026quot;warning: variable \u0026apos;aq_vec\u0026apos; set but not used\u0026quot;\n\nv3. simplified a for loop(CVE-2022-50066)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm raid: fix address sanitizer warning in raid_status\n\nThere is this warning when using a kernel with the address sanitizer\nand running this testsuite:\nhttps://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid\n\n==================================================================\nBUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid]\nRead of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319\nCPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.\u0026lt;snip\u0026gt; #1\nHardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6a/0x9c\n print_address_description.constprop.0+0x1f/0x1e0\n print_report.cold+0x55/0x244\n kasan_report+0xc9/0x100\n raid_status+0x1747/0x2820 [dm_raid]\n dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod]\n table_load+0x35c/0x630 [dm_mod]\n ctl_ioctl+0x411/0x630 [dm_mod]\n dm_ctl_ioctl+0xa/0x10 [dm_mod]\n __x64_sys_ioctl+0x12a/0x1a0\n do_syscall_64+0x5b/0x80\n\nThe warning is caused by reading conf-\u0026gt;max_nr_stripes in raid_status. The\ncode in raid_status reads mddev-\u0026gt;private, casts it to struct r5conf and\nreads the entry max_nr_stripes.\n\nHowever, if we have different raid type than 4/5/6, mddev-\u0026gt;private\ndoesn\u0026apos;t point to struct r5conf; it may point to struct r0conf, struct\nr1conf, struct r10conf or struct mpconf. If we cast a pointer to one\nof these structs to struct r5conf, we will be reading invalid memory\nand KASAN warns about it.\n\nFix this bug by reading struct r5conf only if raid type is 4, 5 or 6.(CVE-2022-50084)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm raid: fix address sanitizer warning in raid_resume\n\nThere is a KASAN warning in raid_resume when running the lvm test\nlvconvert-raid.sh. The reason for the warning is that mddev-\u0026gt;raid_disks\nis greater than rs-\u0026gt;raid_disks, so the loop touches one entry beyond\nthe allocated length.(CVE-2022-50085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails\n\nWhen scpi probe fails, at any point, we need to ensure that the scpi_info\nis not set and will remain NULL until the probe succeeds. If it is not\ntaken care, then it could result use-after-free as the value is exported\nvia get_scpi_ops() and could refer to a memory allocated via devm_kzalloc()\nbut freed when the probe fails.(CVE-2022-50087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts\n\nEnsure SRB is returned during I/O timeout error escalation. If that is not\npossible fail the escalation path.\n\nFollowing crash stack was seen:\n\nBUG: unable to handle kernel paging request at 0000002f56aa90f8\nIP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx]\nCall Trace:\n ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx]\n ? qla2x00_start_sp+0x116/0x1170 [qla2xxx]\n ? dma_pool_alloc+0x1d6/0x210\n ? mempool_alloc+0x54/0x130\n ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx]\n ? qla_do_work+0x2d/0x40 [qla2xxx]\n ? process_one_work+0x14c/0x390(CVE-2022-50098)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched, cpuset: Fix dl_cpu_busy() panic due to empty cs-\u0026gt;cpus_allowed\n\nWith cgroup v2, the cpuset\u0026apos;s cpus_allowed mask can be empty indicating\nthat the cpuset will just use the effective CPUs of its parent. So\ncpuset_can_attach() can call task_can_attach() with an empty mask.\nThis can lead to cpumask_any_and() returns nr_cpu_ids causing the call\nto dl_bw_of() to crash due to percpu value access of an out of bound\nCPU value. For example:\n\n\t[80468.182258] BUG: unable to handle page fault for address: ffffffff8b6648b0\n\t  :\n\t[80468.191019] RIP: 0010:dl_cpu_busy+0x30/0x2b0\n\t  :\n\t[80468.207946] Call Trace:\n\t[80468.208947]  cpuset_can_attach+0xa0/0x140\n\t[80468.209953]  cgroup_migrate_execute+0x8c/0x490\n\t[80468.210931]  cgroup_update_dfl_csses+0x254/0x270\n\t[80468.211898]  cgroup_subtree_control_write+0x322/0x400\n\t[80468.212854]  kernfs_fop_write_iter+0x11c/0x1b0\n\t[80468.213777]  new_sync_write+0x11f/0x1b0\n\t[80468.214689]  vfs_write+0x1eb/0x280\n\t[80468.215592]  ksys_write+0x5f/0xe0\n\t[80468.216463]  do_syscall_64+0x5c/0x80\n\t[80468.224287]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nFix that by using effective_cpus instead. For cgroup v1, effective_cpus\nis the same as cpus_allowed. For v2, effective_cpus is the real cpumask\nto be used by tasks within the cpuset anyway.\n\nAlso update task_can_attach()\u0026apos;s 2nd argument name to cs_effective_cpus to\nreflect the change. In addition, a check is added to task_can_attach()\nto guard against the possibility that cpumask_any_and() may return a\nvalue \u0026gt;= nr_cpu_ids.(CVE-2022-50103)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix error unwind in rxe_create_qp()\n\nIn the function rxe_create_qp(), rxe_qp_from_init() is called to\ninitialize qp, internally things like the spin locks are not setup until\nrxe_qp_init_req().\n\nIf an error occures before this point then the unwind will call\nrxe_cleanup() and eventually to rxe_qp_do_cleanup()/rxe_cleanup_task()\nwhich will oops when trying to access the uninitialized spinlock.\n\nMove the spinlock initializations earlier before any failures.(CVE-2022-50127)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hfi1: fix potential memory leak in setup_base_ctxt()\n\nsetup_base_ctxt() allocates a memory chunk for uctxt-\u0026gt;groups with\nhfi1_alloc_ctxt_rcv_groups(). When init_user_ctxt() fails, uctxt-\u0026gt;groups\nis not released, which will lead to a memory leak.\n\nWe should release the uctxt-\u0026gt;groups with hfi1_free_ctxt_rcv_groups()\nwhen init_user_ctxt() fails.(CVE-2022-50134)\n\nA vulnerability, which was classified as critical, has been found in Linux Kernel up to 5.19.1 (Operating System).Using CWE to declare the problem leads to CWE-911. The product uses a reference count to manage a resource, but it does not update or incorrectly updates the reference count.Impacted is availability.Upgrading to version 4.14.291, 4.19.256, 5.4.211, 5.10.137, 5.15.61, 5.18.18 or 5.19.2 eliminates this vulnerability. Applying the patch 995fb2874bb5696357846a91e59181c600e6aac8/d10855876a6f47add6ff621cef25cc0171dac162/80b1465b2ae81ebb59bbe62bcb7a7f7d4e9ece6f/941ef6997f9db704fe4fd62fc01e420fdd5048b2/d5730780e9ea84e5476752a47c749036c6a74af5/a74322d4b897ddc268b340c4a397f6066c2f945d/babd7b0124650ab71a6487e38588b8659b3aa2dc/77087a04c8fd554134bddcb8a9ff87b21f357926 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2022-50160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: fix potential buffer overflow in ni_set_mc_special_registers()\n\nThe last case label can write two buffers \u0026apos;mc_reg_address[j]\u0026apos; and\n\u0026apos;mc_data[j]\u0026apos; with \u0026apos;j\u0026apos; offset equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE\nsince there are no checks for this value in both case labels after the\nlast \u0026apos;j++\u0026apos;.\n\nInstead of changing \u0026apos;\u0026gt;\u0026apos; to \u0026apos;\u0026gt;=\u0026apos; there, add the bounds check at the start\nof the second \u0026apos;case\u0026apos; (the first one already has it).\n\nAlso, remove redundant last checks for \u0026apos;j\u0026apos; index bigger than array size.\nThe expression is always false. Moreover, before or after the patch\n\u0026apos;table-\u0026gt;last\u0026apos; can be equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE and it\nseems it can be a valid value.\n\nDetected using the static analysis tool - Svace.(CVE-2022-50185)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: of: Fix refcount leak bug in of_get_regulation_constraints()\n\nWe should call the of_node_put() for the reference returned by\nof_get_child_by_name() which has increased the refcount.(CVE-2022-50191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPM: hibernate: defer device probing when resuming from hibernation\n\nsyzbot is reporting hung task at misc_open() [1], for there is a race\nwindow of AB-BA deadlock which involves probe_count variable. Currently\nwait_for_device_probe() from snapshot_open() from misc_open() can sleep\nforever with misc_mtx held if probe_count cannot become 0.\n\nWhen a device is probed by hub_event() work function, probe_count is\nincremented before the probe function starts, and probe_count is\ndecremented after the probe function completed.\n\nThere are three cases that can prevent probe_count from dropping to 0.\n\n  (a) A device being probed stopped responding (i.e. broken/malicious\n      hardware).\n\n  (b) A process emulating a USB device using /dev/raw-gadget interface\n      stopped responding for some reason.\n\n  (c) New device probe requests keeps coming in before existing device\n      probe requests complete.\n\nThe phenomenon syzbot is reporting is (b). A process which is holding\nsystem_transition_mutex and misc_mtx is waiting for probe_count to become\n0 inside wait_for_device_probe(), but the probe function which is called\n from hub_event() work function is waiting for the processes which are\nblocked at mutex_lock(\u0026amp;misc_mtx) to respond via /dev/raw-gadget interface.\n\nThis patch mitigates (b) by deferring wait_for_device_probe() from\nsnapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that\nthe possibility of (b) remains as long as any thread which is emulating a\nUSB device via /dev/raw-gadget interface can be blocked by uninterruptible\nblocking operations (e.g. mutex_lock()).\n\nPlease also note that (a) and (c) are not addressed. Regarding (c), we\nshould change the code to wait for only one device which contains the\nimage for resuming from hibernation. I don\u0026apos;t know how to address (a), for\nuse of timeout for wait_for_device_probe() might result in loss of user\ndata in the image. Maybe we should require the userland to wait for the\nimage device before opening /dev/snapshot interface.(CVE-2022-50202)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd-raid10: fix KASAN warning\n\nThere\u0026apos;s a KASAN warning in raid10_remove_disk when running the lvm\ntest lvconvert-raid-reshape.sh. We fix this warning by verifying that the\nvalue \u0026quot;number\u0026quot; is valid.\n\nBUG: KASAN: slab-out-of-bounds in raid10_remove_disk+0x61/0x2a0 [raid10]\nRead of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682\n\nCPU: 3 PID: 124682 Comm: mdX_raid10 Not tainted 5.19.0-rc6 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x34/0x44\n print_report.cold+0x45/0x57a\n ? __lock_text_start+0x18/0x18\n ? raid10_remove_disk+0x61/0x2a0 [raid10]\n kasan_report+0xa8/0xe0\n ? raid10_remove_disk+0x61/0x2a0 [raid10]\n raid10_remove_disk+0x61/0x2a0 [raid10]\nBuffer I/O error on dev dm-76, logical block 15344, async page read\n ? __mutex_unlock_slowpath.constprop.0+0x1e0/0x1e0\n remove_and_add_spares+0x367/0x8a0 [md_mod]\n ? super_written+0x1c0/0x1c0 [md_mod]\n ? mutex_trylock+0xac/0x120\n ? _raw_spin_lock+0x72/0xc0\n ? _raw_spin_lock_bh+0xc0/0xc0\n md_check_recovery+0x848/0x960 [md_mod]\n raid10d+0xcf/0x3360 [raid10]\n ? sched_clock_cpu+0x185/0x1a0\n ? rb_erase+0x4d4/0x620\n ? var_wake_function+0xe0/0xe0\n ? psi_group_change+0x411/0x500\n ? preempt_count_sub+0xf/0xc0\n ? _raw_spin_lock_irqsave+0x78/0xc0\n ? __lock_text_start+0x18/0x18\n ? raid10_sync_request+0x36c0/0x36c0 [raid10]\n ? preempt_count_sub+0xf/0xc0\n ? _raw_spin_unlock_irqrestore+0x19/0x40\n ? del_timer_sync+0xa9/0x100\n ? try_to_del_timer_sync+0xc0/0xc0\n ? _raw_spin_lock_irqsave+0x78/0xc0\n ? __lock_text_start+0x18/0x18\n ? _raw_spin_unlock_irq+0x11/0x24\n ? __list_del_entry_valid+0x68/0xa0\n ? finish_wait+0xa3/0x100\n md_thread+0x161/0x260 [md_mod]\n ? unregister_md_personality+0xa0/0xa0 [md_mod]\n ? _raw_spin_lock_irqsave+0x78/0xc0\n ? prepare_to_wait_event+0x2c0/0x2c0\n ? unregister_md_personality+0xa0/0xa0 [md_mod]\n kthread+0x148/0x180\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 124495:\n kasan_save_stack+0x1e/0x40\n __kasan_kmalloc+0x80/0xa0\n setup_conf+0x140/0x5c0 [raid10]\n raid10_run+0x4cd/0x740 [raid10]\n md_run+0x6f9/0x1300 [md_mod]\n raid_ctr+0x2531/0x4ac0 [dm_raid]\n dm_table_add_target+0x2b0/0x620 [dm_mod]\n table_load+0x1c8/0x400 [dm_mod]\n ctl_ioctl+0x29e/0x560 [dm_mod]\n dm_compat_ctl_ioctl+0x7/0x20 [dm_mod]\n __do_compat_sys_ioctl+0xfa/0x160\n do_syscall_64+0x90/0xc0\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nLast potentially related work creation:\n kasan_save_stack+0x1e/0x40\n __kasan_record_aux_stack+0x9e/0xc0\n kvfree_call_rcu+0x84/0x480\n timerfd_release+0x82/0x140\nL __fput+0xfa/0x400\n task_work_run+0x80/0xc0\n exit_to_user_mode_prepare+0x155/0x160\n syscall_exit_to_user_mode+0x12/0x40\n do_syscall_64+0x42/0xc0\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nSecond to last potentially related work creation:\n kasan_save_stack+0x1e/0x40\n __kasan_record_aux_stack+0x9e/0xc0\n kvfree_call_rcu+0x84/0x480\n timerfd_release+0x82/0x140\n __fput+0xfa/0x400\n task_work_run+0x80/0xc0\n exit_to_user_mode_prepare+0x155/0x160\n syscall_exit_to_user_mode+0x12/0x40\n do_syscall_64+0x42/0xc0\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThe buggy address belongs to the object at ffff889108f3d200\n which belongs to the cache kmalloc-256 of size 256\nThe buggy address is located 0 bytes to the right of\n 256-byte region [ffff889108f3d200, ffff889108f3d300)\n\nThe buggy address belongs to the physical page:\npage:000000007ef2a34c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1108f3c\nhead:000000007ef2a34c order:2 compound_mapcount:0 compound_pincount:0\nflags: 0x4000000000010200(slab|head|zone=2)\nraw: 4000000000010200 0000000000000000 dead000000000001 ffff889100042b40\nraw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffff889108f3d200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffff889108f3d280: 00 00\n---truncated---(CVE-2022-50211)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: Fix linkwatch use-after-free on disconnect\n\nusbnet uses the work usbnet_deferred_kevent() to perform tasks which may\nsleep.  On disconnect, completion of the work was originally awaited in\n-\u0026gt;ndo_stop().  But in 2003, that was moved to -\u0026gt;disconnect() by historic\ncommit \u0026quot;[PATCH] USB: usbnet, prevent exotic rtnl deadlock\u0026quot;:\n\n  https://git.kernel.org/tglx/history/c/0f138bbfd83c\n\nThe change was made because back then, the kernel\u0026apos;s workqueue\nimplementation did not allow waiting for a single work.  One had to wait\nfor completion of *all* work by calling flush_scheduled_work(), and that\ncould deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutex\nheld in -\u0026gt;ndo_stop().\n\nThe commit solved one problem but created another:  It causes a\nuse-after-free in USB Ethernet drivers aqc111.c, asix_devices.c,\nax88179_178a.c, ch9200.c and smsc75xx.c:\n\n* If the drivers receive a link change interrupt immediately before\n  disconnect, they raise EVENT_LINK_RESET in their (non-sleepable)\n  -\u0026gt;status() callback and schedule usbnet_deferred_kevent().\n* usbnet_deferred_kevent() invokes the driver\u0026apos;s -\u0026gt;link_reset() callback,\n  which calls netif_carrier_{on,off}().\n* That in turn schedules the work linkwatch_event().\n\nBecause usbnet_deferred_kevent() is awaited after unregister_netdev(),\nnetif_carrier_{on,off}() may operate on an unregistered netdev and\nlinkwatch_event() may run after free_netdev(), causing a use-after-free.\n\nIn 2010, usbnet was changed to only wait for a single instance of\nusbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf\n(\u0026quot;drivers/net: don\u0026apos;t use flush_scheduled_work()\u0026quot;).\n\nUnfortunately the commit neglected to move the wait back to\n-\u0026gt;ndo_stop().  Rectify that omission at long last.(CVE-2022-50220)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Don\u0026apos;t BUG if userspace injects an interrupt with GIF=0\n\nDon\u0026apos;t BUG/WARN on interrupt injection due to GIF being cleared,\nsince it\u0026apos;s trivial for userspace to force the situation via\nKVM_SET_VCPU_EVENTS (even if having at least a WARN there would be correct\nfor KVM internally generated injections).\n\n  kernel BUG at arch/x86/kvm/svm/svm.c:3386!\n  invalid opcode: 0000 [#1] SMP\n  CPU: 15 PID: 926 Comm: smm_test Not tainted 5.17.0-rc3+ #264\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  RIP: 0010:svm_inject_irq+0xab/0xb0 [kvm_amd]\n  Code: \u0026lt;0f\u0026gt; 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53\n  RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246\n  RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006\n  RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0\n  RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000\n  R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000\n  FS:  0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   inject_pending_event+0x2f7/0x4c0 [kvm]\n   kvm_arch_vcpu_ioctl_run+0x791/0x17a0 [kvm]\n   kvm_vcpu_ioctl+0x26d/0x650 [kvm]\n   __x64_sys_ioctl+0x82/0xb0\n   do_syscall_64+0x3b/0xc0\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n   \u0026lt;/TASK\u0026gt;(CVE-2022-50228)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: bcd2000: Fix a UAF bug on the error path of probing\n\nWhen the driver fails in snd_card_register() at probe time, it will free\nthe \u0026apos;bcd2k-\u0026gt;midi_out_urb\u0026apos; before killing it, which may cause a UAF bug.\n\nThe following log can reveal it:\n\n[   50.727020] BUG: KASAN: use-after-free in bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000]\n[   50.727623] Read of size 8 at addr ffff88810fab0e88 by task swapper/4/0\n[   50.729530] Call Trace:\n[   50.732899]  bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000]\n\nFix this by adding usb_kill_urb() before usb_free_urb().(CVE-2022-50229)\n\nA heap out-of-bounds write vulnerability in the Linux Kernel ipvlan network driver can be exploited to achieve local privilege escalation.The out-of-bounds write is caused by missing skb-\u0026gt;cb  initialization in the ipvlan network driver. The vulnerability is reachable if CONFIG_IPVLAN is enabled.We recommend upgrading past commit 90cbed5247439a966b645b34eb0a2e037836ea8e.(CVE-2023-3090)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: tunnels: annotate lockless accesses to dev-\u0026gt;needed_headroom\n\nIP tunnels can apparently update dev-\u0026gt;needed_headroom\nin their xmit path.\n\nThis patch takes care of three tunnels xmit, and also the\ncore LL_RESERVED_SPACE() and LL_RESERVED_SPACE_EXTRA()\nhelpers.\n\nMore changes might be needed for completeness.\n\nBUG: KCSAN: data-race in ip_tunnel_xmit / ip_tunnel_xmit\n\nread to 0xffff88815b9da0ec of 2 bytes by task 888 on cpu 1:\nip_tunnel_xmit+0x1270/0x1730 net/ipv4/ip_tunnel.c:803\n__gre_xmit net/ipv4/ip_gre.c:469 [inline]\nipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661\n__netdev_start_xmit include/linux/netdevice.h:4881 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4895 [inline]\nxmit_one net/core/dev.c:3580 [inline]\ndev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596\n__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246\ndev_queue_xmit include/linux/netdevice.h:3051 [inline]\nneigh_direct_output+0x17/0x20 net/core/neighbour.c:1623\nneigh_output include/net/neighbour.h:546 [inline]\nip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228\nip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316\nNF_HOOK_COND include/linux/netfilter.h:291 [inline]\nip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430\ndst_output include/net/dst.h:444 [inline]\nip_local_out+0x64/0x80 net/ipv4/ip_output.c:126\niptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82\nip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813\n__gre_xmit net/ipv4/ip_gre.c:469 [inline]\nipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661\n__netdev_start_xmit include/linux/netdevice.h:4881 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4895 [inline]\nxmit_one net/core/dev.c:3580 [inline]\ndev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596\n__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246\ndev_queue_xmit include/linux/netdevice.h:3051 [inline]\nneigh_direct_output+0x17/0x20 net/core/neighbour.c:1623\nneigh_output include/net/neighbour.h:546 [inline]\nip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228\nip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316\nNF_HOOK_COND include/linux/netfilter.h:291 [inline]\nip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430\ndst_output include/net/dst.h:444 [inline]\nip_local_out+0x64/0x80 net/ipv4/ip_output.c:126\niptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82\nip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813\n__gre_xmit net/ipv4/ip_gre.c:469 [inline]\nipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661\n__netdev_start_xmit include/linux/netdevice.h:4881 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4895 [inline]\nxmit_one net/core/dev.c:3580 [inline]\ndev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596\n__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246\ndev_queue_xmit include/linux/netdevice.h:3051 [inline]\nneigh_direct_output+0x17/0x20 net/core/neighbour.c:1623\nneigh_output include/net/neighbour.h:546 [inline]\nip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228\nip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316\nNF_HOOK_COND include/linux/netfilter.h:291 [inline]\nip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430\ndst_output include/net/dst.h:444 [inline]\nip_local_out+0x64/0x80 net/ipv4/ip_output.c:126\niptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82\nip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813\n__gre_xmit net/ipv4/ip_gre.c:469 [inline]\nipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661\n__netdev_start_xmit include/linux/netdevice.h:4881 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4895 [inline]\nxmit_one net/core/dev.c:3580 [inline]\ndev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596\n__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246\ndev_queue_xmit include/linux/netdevice.h:3051 [inline]\nneigh_direct_output+0x17/0x20 net/core/neighbour.c:1623\nneigh_output include/net/neighbour.h:546 [inline]\nip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228\nip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316\nNF_HOOK_COND include/linux/netfilter.h:291 [inline]\nip_output+0xe5/0x1b0 net/i\n---truncated---(CVE-2023-53109)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix out-of-bound memcpy() during ethtool -w\n\nWhen retrieving the FW coredump using ethtool, it can sometimes cause\nmemory corruption:\n\nBUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]\nCorrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):\n__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]\nethtool_get_dump_data+0xdc/0x1a0\n__dev_ethtool+0xa1e/0x1af0\ndev_ethtool+0xa8/0x170\ndev_ioctl+0x1b5/0x580\nsock_do_ioctl+0xab/0xf0\nsock_ioctl+0x1ce/0x2e0\n__x64_sys_ioctl+0x87/0xc0\ndo_syscall_64+0x5c/0xf0\nentry_SYSCALL_64_after_hwframe+0x78/0x80\n\n...\n\nThis happens when copying the coredump segment list in\nbnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.\nThe info-\u0026gt;dest_buf buffer is allocated based on the number of coredump\nsegments returned by the FW.  The segment list is then DMA\u0026apos;ed by\nthe FW and the length of the DMA is returned by FW.  The driver then\ncopies this DMA\u0026apos;ed segment list to info-\u0026gt;dest_buf.\n\nIn some cases, this DMA length may exceed the info-\u0026gt;dest_buf length\nand cause the above BUG condition.  Fix it by capping the copy\nlength to not exceed the length of info-\u0026gt;dest_buf.  The extra\nDMA data contains no useful information.\n\nThis code path is shared for the HWRM_DBG_COREDUMP_LIST and the\nHWRM_DBG_COREDUMP_RETRIEVE FW commands.  The buffering is different\nfor these 2 FW commands.  To simplify the logic, we need to move\nthe line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE\nup, so that the new check to cap the copy length will work for both\ncommands.(CVE-2025-37911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_htb: make htb_qlen_notify() idempotent\n\nhtb_qlen_notify() always deactivates the HTB class and in fact could\ntrigger a warning if it is already deactivated. Therefore, it is not\nidempotent and not friendly to its callers, like fq_codel_dequeue().\n\nLet\u0026apos;s make it idempotent to ease qdisc_tree_reduce_backlog() callers\u0026apos;\nlife.(CVE-2025-37932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfs: handle failure of nfs_get_lock_context in unlock path\n\nWhen memory is insufficient, the allocation of nfs_lock_context in\nnfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat\nan nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)\nas valid and proceed to execute rpc_run_task(), this will trigger a NULL\npointer dereference in nfs4_locku_prepare. For example:\n\nBUG: kernel NULL pointer dereference, address: 000000000000000c\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP PTI\nCPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40\nWorkqueue: rpciod rpc_async_schedule\nRIP: 0010:nfs4_locku_prepare+0x35/0xc2\nCode: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3\nRSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246\nRAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40\nRBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38\nR10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030\nR13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30\nFS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __rpc_execute+0xbc/0x480\n rpc_async_schedule+0x2f/0x40\n process_one_work+0x232/0x5d0\n worker_thread+0x1da/0x3d0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x10d/0x240\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in:\nCR2: 000000000000000c\n---[ end trace 0000000000000000 ]---\n\nFree the allocated nfs4_unlockdata when nfs_get_lock_context() fails and\nreturn NULL to terminate subsequent rpc_run_task, preventing NULL pointer\ndereference.(CVE-2025-38023)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcf/0x610 mm/kasan/report.c:489\n kasan_report+0xb5/0xe0 mm/kasan/report.c:602\n rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195\n rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132\n __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232\n rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109\n create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052\n ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095\n ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679\n vfs_write fs/read_write.c:677 [inline]\n vfs_write+0x26a/0xcc0 fs/read_write.c:659\n ksys_write+0x1b8/0x200 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nIn the function rxe_create_cq, when rxe_cq_from_init fails, the function\nrxe_cleanup will be called to handle the allocated resources. In fact,\nsome memory resources have already been freed in the function\nrxe_cq_from_init. Thus, this problem will occur.\n\nThe solution is to let rxe_cleanup do all the work.(CVE-2025-38024)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm: fix unconditional IO throttle caused by REQ_PREFLUSH\n\nWhen a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush()\ngenerates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC,\nwhich causes the flush_bio to be throttled by wbt_wait().\n\nAn example from v5.4, similar problem also exists in upstream:\n\n    crash\u0026gt; bt 2091206\n    PID: 2091206  TASK: ffff2050df92a300  CPU: 109  COMMAND: \u0026quot;kworker/u260:0\u0026quot;\n     #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8\n     #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4\n     #2 [ffff800084a2f880] schedule at ffff800040bfa4b4\n     #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4\n     #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc\n     #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0\n     #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254\n     #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38\n     #8 [ffff800084a2fa60] generic_make_request at ffff800040570138\n     #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4\n    #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs]\n    #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs]\n    #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs]\n    #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs]\n    #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs]\n    #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs]\n    #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08\n    #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc\n    #18 [ffff800084a2fe70] kthread at ffff800040118de4\n\nAfter commit 2def2845cc33 (\u0026quot;xfs: don\u0026apos;t allow log IO to be throttled\u0026quot;),\nthe metadata submitted by xlog_write_iclog() should not be throttled.\nBut due to the existence of the dm layer, throttling flush_bio indirectly\ncauses the metadata bio to be throttled.\n\nFix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makes\nwbt_should_throttle() return false to avoid wbt_wait().(CVE-2025-38063)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_hash - fix double free in hash_accept\n\nIf accept(2) is called on socket type algif_hash with\nMSG_MORE flag set and crypto_ahash_import fails,\nsk2 is freed. However, it is also freed in af_alg_release,\nleading to slab-use-after-free error.(CVE-2025-38079)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2507.2.0.0335.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm","kernel-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm","perf-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2507.2.0.0335.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2507.2.0.0335.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm","kernel-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm","perf-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2507.2.0.0335.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1820"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49862"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49871"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49881"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49907"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49918"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49921"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49934"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49938"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49942"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49948"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49964"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49969"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49986"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49987"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49989"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50022"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50033"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50053"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50066"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50084"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50085"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50087"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50098"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50103"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50127"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50134"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50160"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50185"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50191"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50202"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50211"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50220"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50228"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50229"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-3090"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53109"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37911"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37932"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38023"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38024"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38063"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38079"}],"database_specific":{"severity":"High"}}