{"schema_version":"1.7.2","id":"OESA-2025-1336","modified":"2025-03-29T06:23:03Z","published":"2025-03-29T06:23:03Z","upstream":["CVE-2021-47659","CVE-2022-49053","CVE-2022-49243","CVE-2022-49292","CVE-2022-49335","CVE-2022-49350","CVE-2022-49381","CVE-2022-49388","CVE-2022-49490","CVE-2022-49508","CVE-2022-49535","CVE-2022-49603","CVE-2022-49625","CVE-2022-49678","CVE-2022-49713","CVE-2022-49720","CVE-2022-49727","CVE-2025-21687","CVE-2025-21806"],"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\ndrm/plane: Move range check for format_count earlier\n\nWhile the check for format_count \u0026gt; 64 in __drm_universal_plane_init()\nshouldn\u0026apos;t be hit (it\u0026apos;s a WARN_ON), in its current position it will then\nleak the plane-\u0026gt;format_types array and fail to call\ndrm_mode_object_unregister() leaking the modeset identifier. Move it to\nthe start of the function to avoid allocating those resources in the\nfirst place.(CVE-2021-47659)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: tcmu: Fix possible page UAF\n\ntcmu_try_get_data_page() looks up pages under cmdr_lock, but it does not\ntake refcount properly and just returns page pointer. When\ntcmu_try_get_data_page() returns, the returned page may have been freed by\ntcmu_blocks_release().\n\nWe need to get_page() under cmdr_lock to avoid concurrent\ntcmu_blocks_release().(CVE-2022-49053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: atmel: Add missing of_node_put() in at91sam9g20ek_audio_probe\n\nThis node pointer is returned by of_parse_phandle() with refcount\nincremented in this function.\nCalling of_node_put() to avoid the refcount leak.(CVE-2022-49243)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: oss: Fix PCM OSS buffer allocation overflow\n\nWe\u0026apos;ve got syzbot reports hitting INT_MAX overflow at vmalloc()\nallocation that is called from snd_pcm_plug_alloc().  Although we\napply the restrictions to input parameters, it\u0026apos;s based only on the\nhw_params of the underlying PCM device.  Since the PCM OSS layer\nallocates a temporary buffer for the data conversion, the size may\nbecome unexpectedly large when more channels or higher rates is given;\nin the reported case, it went over INT_MAX, hence it hits WARN_ON().\n\nThis patch is an attempt to avoid such an overflow and an allocation\nfor too large buffers.  First off, it adds the limit of 1MB as the\nupper bound for period bytes.  This must be large enough for all use\ncases, and we really don\u0026apos;t want to handle a larger temporary buffer\nthan this size.  The size check is performed at two places, where the\noriginal period bytes is calculated and where the plugin buffer size\nis calculated.\n\nIn addition, the driver uses array_size() and array3_size() for\nmultiplications to catch overflows for the converted period size and\nbuffer bytes.(CVE-2022-49292)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/cs: make commands with 0 chunks illegal behaviour.\n\nSubmitting a cs with 0 chunks, causes an oops later, found trying\nto execute the wrong userspace driver.\n\nMESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo\n\n[172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8\n[172536.665188] #PF: supervisor read access in kernel mode\n[172536.665189] #PF: error_code(0x0000) - not-present page\n[172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0\n[172536.665195] Oops: 0000 [#1] SMP NOPTI\n[172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P           O      5.10.81 #1-NixOS\n[172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015\n[172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu]\n[172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 \u0026lt;48\u0026gt; 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10\n[172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246\n[172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\n[172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68\n[172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38\n[172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40\n[172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28\n[172536.665283] FS:  00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000\n[172536.665284] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0\n[172536.665287] Call Trace:\n[172536.665322]  ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]\n[172536.665332]  drm_ioctl_kernel+0xaa/0xf0 [drm]\n[172536.665338]  drm_ioctl+0x201/0x3b0 [drm]\n[172536.665369]  ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]\n[172536.665372]  ? selinux_file_ioctl+0x135/0x230\n[172536.665399]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]\n[172536.665403]  __x64_sys_ioctl+0x83/0xb0\n[172536.665406]  do_syscall_64+0x33/0x40\n[172536.665409]  entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\nBug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018(CVE-2022-49335)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: mdio: unexport __init-annotated mdio_bus_init()\n\nEXPORT_SYMBOL and __init is a bad combination because the .init.text\nsection is freed up after the initialization. Hence, modules cannot\nuse symbols annotated __init. The access to a freed symbol may end up\nwith kernel panic.\n\nmodpost used to detect it, but it has been broken for a decade.\n\nRecently, I fixed modpost so it started to warn it again, then this\nshowed up in linux-next builds.\n\nThere are two ways to fix it:\n\n  - Remove __init\n  - Remove EXPORT_SYMBOL\n\nI chose the latter for this case because the only in-tree call-site,\ndrivers/net/phy/phy_device.c is never compiled as modular.\n(CONFIG_PHYLIB is boolean)(CVE-2022-49350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njffs2: fix memory leak in jffs2_do_fill_super\n\nIf jffs2_iget() or d_make_root() in jffs2_do_fill_super() returns\nan error, we can observe the following kmemleak report:\n\n--------------------------------------------\nunreferenced object 0xffff888105a65340 (size 64):\n  comm \u0026quot;mount\u0026quot;, pid 710, jiffies 4302851558 (age 58.239s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [\u0026lt;ffffffff859c45e5\u0026gt;] kmem_cache_alloc_trace+0x475/0x8a0\n    [\u0026lt;ffffffff86160146\u0026gt;] jffs2_sum_init+0x96/0x1a0\n    [\u0026lt;ffffffff86140e25\u0026gt;] jffs2_do_mount_fs+0x745/0x2120\n    [\u0026lt;ffffffff86149fec\u0026gt;] jffs2_do_fill_super+0x35c/0x810\n    [\u0026lt;ffffffff8614aae9\u0026gt;] jffs2_fill_super+0x2b9/0x3b0\n    [...]\nunreferenced object 0xffff8881bd7f0000 (size 65536):\n  comm \u0026quot;mount\u0026quot;, pid 710, jiffies 4302851558 (age 58.239s)\n  hex dump (first 32 bytes):\n    bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb  ................\n    bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb  ................\n  backtrace:\n    [\u0026lt;ffffffff858579ba\u0026gt;] kmalloc_order+0xda/0x110\n    [\u0026lt;ffffffff85857a11\u0026gt;] kmalloc_order_trace+0x21/0x130\n    [\u0026lt;ffffffff859c2ed1\u0026gt;] __kmalloc+0x711/0x8a0\n    [\u0026lt;ffffffff86160189\u0026gt;] jffs2_sum_init+0xd9/0x1a0\n    [\u0026lt;ffffffff86140e25\u0026gt;] jffs2_do_mount_fs+0x745/0x2120\n    [\u0026lt;ffffffff86149fec\u0026gt;] jffs2_do_fill_super+0x35c/0x810\n    [\u0026lt;ffffffff8614aae9\u0026gt;] jffs2_fill_super+0x2b9/0x3b0\n    [...]\n--------------------------------------------\n\nThis is because the resources allocated in jffs2_sum_init() are not\nreleased. Call jffs2_sum_exit() to release these resources to solve\nthe problem.(CVE-2022-49381)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nubi: ubi_create_volume: Fix use-after-free when volume creation failed\n\nThere is an use-after-free problem for \u0026apos;eba_tbl\u0026apos; in ubi_create_volume()\u0026apos;s\nerror handling path:\n\n  ubi_eba_replace_table(vol, eba_tbl)\n    vol-\u0026gt;eba_tbl = tbl\nout_mapping:\n  ubi_eba_destroy_table(eba_tbl)   // Free \u0026apos;eba_tbl\u0026apos;\nout_unlock:\n  put_device(\u0026amp;vol-\u0026gt;dev)\n    vol_release\n      kfree(tbl-\u0026gt;entries)\t  // UAF\n\nFix it by removing redundant \u0026apos;eba_tbl\u0026apos; releasing.\nFetch a reproducer in [Link].(CVE-2022-49388)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected\n\nmdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring\nthe modeset lock, but currently mdp5_pipe_release doesn\u0026apos;t check for if\nan error is returned. Because of this, there is a possibility of\nmdp5_pipe_release hitting a NULL dereference error.\n\nTo avoid this, let\u0026apos;s have mdp5_pipe_release check if\nmdp5_get_global_state returns an error and propogate that error.\n\nChanges since v1:\n- Separated declaration and initialization of *new_state to avoid\n  compiler warning\n- Fixed some spelling mistakes in commit message\n\nChanges since v2:\n- Return 0 in case where hwpipe is NULL as this is considered normal\n  behavior\n- Added 2nd patch in series to fix a similar NULL dereference issue in\n  mdp5_mixer_release\n\nPatchwork: https://patchwork.freedesktop.org/patch/485179/(CVE-2022-49490)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: elan: Fix potential double free in elan_input_configured\n\n\u0026apos;input\u0026apos; is a managed resource allocated with devm_input_allocate_device(),\nso there is no need to call input_free_device() explicitly or\nthere will be a double free.\n\nAccording to the doc of devm_input_allocate_device():\n * Managed input devices do not need to be explicitly unregistered or\n * freed as it will be done automatically when owner device unbinds from\n * its driver (or binding fails).(CVE-2022-49508)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI\n\nIf lpfc_issue_els_flogi() fails and returns non-zero status, the node\nreference count is decremented to trigger the release of the nodelist\nstructure. However, if there is a prior registration or dev-loss-evt work\npending, the node may be released prematurely.  When dev-loss-evt\ncompletes, the released node is referenced causing a use-after-free null\npointer dereference.\n\nSimilarly, when processing non-zero ELS PLOGI completion status in\nlpfc_cmpl_els_plogi(), the ndlp flags are checked for a transport\nregistration before triggering node removal.  If dev-loss-evt work is\npending, the node may be released prematurely and a subsequent call to\nlpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference.\n\nAdd test for pending dev-loss before decrementing the node reference count\nfor FLOGI, PLOGI, PRLI, and ADISC handling.(CVE-2022-49535)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip: Fix data-races around sysctl_ip_fwd_update_priority.\n\nWhile reading sysctl_ip_fwd_update_priority, it can be changed\nconcurrently.  Thus, we need to add READ_ONCE() to its readers.(CVE-2022-49603)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsfc: fix kernel panic when creating VF\n\nWhen creating VFs a kernel panic can happen when calling to\nefx_ef10_try_update_nic_stats_vf.\n\nWhen releasing a DMA coherent buffer, sometimes, I don\u0026apos;t know in what\nspecific circumstances, it has to unmap memory with vunmap. It is\ndisallowed to do that in IRQ context or with BH disabled. Otherwise, we\nhit this line in vunmap, causing the crash:\n  BUG_ON(in_interrupt());\n\nThis patch reenables BH to release the buffer.\n\nLog messages when the bug is hit:\n kernel BUG at mm/vmalloc.c:2727!\n invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 6 PID: 1462 Comm: NetworkManager Kdump: loaded Tainted: G          I      --------- ---  5.14.0-119.el9.x86_64 #1\n Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020\n RIP: 0010:vunmap+0x2e/0x30\n ...skip...\n Call Trace:\n  __iommu_dma_free+0x96/0x100\n  efx_nic_free_buffer+0x2b/0x40 [sfc]\n  efx_ef10_try_update_nic_stats_vf+0x14a/0x1c0 [sfc]\n  efx_ef10_update_stats_vf+0x18/0x40 [sfc]\n  efx_start_all+0x15e/0x1d0 [sfc]\n  efx_net_open+0x5a/0xe0 [sfc]\n  __dev_open+0xe7/0x1a0\n  __dev_change_flags+0x1d7/0x240\n  dev_change_flags+0x21/0x60\n  ...skip...(CVE-2022-49625)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in brcmstb_pm_probe\n\nof_find_matching_node() returns a node pointer with refcount\nincremented, we should use of_node_put() on it when not need anymore.\nAdd missing of_node_put() to avoid refcount leak.\n\nIn brcmstb_init_sram, it pass dn to of_address_to_resource(),\nof_address_to_resource() will call of_find_device_by_node() to take\nreference, so we should release the reference returned by\nof_find_matching_node().(CVE-2022-49678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc2: Fix memory leak in dwc2_hcd_init\n\nusb_create_hcd will alloc memory for hcd, and we should\ncall usb_put_hcd to free it when platform_get_resource()\nfails to prevent memory leak.\ngoto error2 label instead error1 to fix this.(CVE-2022-49713)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock: Fix handling of offline queues in blk_mq_alloc_request_hctx()\n\nThis patch prevents that test nvme/004 triggers the following:\n\nUBSAN: array-index-out-of-bounds in block/blk-mq.h:135:9\nindex 512 is out of range for type \u0026apos;long unsigned int [512]\u0026apos;\nCall Trace:\n show_stack+0x52/0x58\n dump_stack_lvl+0x49/0x5e\n dump_stack+0x10/0x12\n ubsan_epilogue+0x9/0x3b\n __ubsan_handle_out_of_bounds.cold+0x44/0x49\n blk_mq_alloc_request_hctx+0x304/0x310\n __nvme_submit_sync_cmd+0x70/0x200 [nvme_core]\n nvmf_connect_io_queue+0x23e/0x2a0 [nvme_fabrics]\n nvme_loop_connect_io_queues+0x8d/0xb0 [nvme_loop]\n nvme_loop_create_ctrl+0x58e/0x7d0 [nvme_loop]\n nvmf_create_ctrl+0x1d7/0x4d0 [nvme_fabrics]\n nvmf_dev_write+0xae/0x111 [nvme_fabrics]\n vfs_write+0x144/0x560\n ksys_write+0xb7/0x140\n __x64_sys_write+0x42/0x50\n do_syscall_64+0x35/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2022-49720)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix signed integer overflow in l2tp_ip6_sendmsg\n\nWhen len \u0026gt;= INT_MAX - transhdrlen, ulen = len + transhdrlen will be\noverflow. To fix, we can follow what udpv6 does and subtract the\ntranshdrlen from the max.(CVE-2022-49727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/platform: check the bounds of read/write syscalls\n\ncount and offset are passed from user space and not checked, only\noffset is capped to 40 bits, which can be used to read/write out of\nbounds of the device.(CVE-2025-21687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: let net.core.dev_weight always be non-zero\n\nThe following problem was encountered during stability test:\n\n(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \\\n\treturned 1, exceeding its budget of 0.\n------------[ cut here ]------------\nlist_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \\\n\tnext=ffff88905f746e40.\nWARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \\\n\t__list_add_valid_or_report+0xf3/0x130\nCPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+\nRIP: 0010:__list_add_valid_or_report+0xf3/0x130\nCall Trace:\n? __warn+0xcd/0x250\n? __list_add_valid_or_report+0xf3/0x130\nenqueue_to_backlog+0x923/0x1070\nnetif_rx_internal+0x92/0x2b0\n__netif_rx+0x15/0x170\nloopback_xmit+0x2ef/0x450\ndev_hard_start_xmit+0x103/0x490\n__dev_queue_xmit+0xeac/0x1950\nip_finish_output2+0x6cc/0x1620\nip_output+0x161/0x270\nip_push_pending_frames+0x155/0x1a0\nraw_sendmsg+0xe13/0x1550\n__sys_sendto+0x3bf/0x4e0\n__x64_sys_sendto+0xdc/0x1b0\ndo_syscall_64+0x5b/0x170\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe reproduction command is as follows:\n  sysctl -w net.core.dev_weight=0\n  ping 127.0.0.1\n\nThis is because when the napi\u0026apos;s weight is set to 0, process_backlog() may\nreturn 0 and clear the NAPI_STATE_SCHED bit of napi-\u0026gt;state, causing this\nnapi to be re-polled in net_rx_action() until __do_softirq() times out.\nSince the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can\nbe retriggered in enqueue_to_backlog(), causing this issue.\n\nMaking the napi\u0026apos;s weight always non-zero solves this problem.\n\nTriggering this issue requires system-wide admin (setting is\nnot namespaced).(CVE-2025-21806)","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-2503.5.0.0321.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm","kernel-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm","perf-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2503.5.0.0321.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2503.5.0.0321.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm","kernel-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm","perf-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2503.5.0.0321.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1336"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47659"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49053"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49243"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49292"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49335"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49350"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49381"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49388"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49490"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49508"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49535"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49603"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49625"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49678"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49713"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49720"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49727"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21687"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21806"}],"database_specific":{"severity":"High"}}