{"schema_version":"1.7.2","id":"OESA-2025-2805","modified":"2025-12-12T12:20:15Z","published":"2025-12-12T12:20:15Z","upstream":["CVE-2022-50243","CVE-2022-50252","CVE-2022-50258","CVE-2022-50321","CVE-2022-50555","CVE-2023-53148","CVE-2023-53153","CVE-2023-53222","CVE-2025-38470","CVE-2025-38617"],"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\nsctp: handle the error returned from sctp_auth_asoc_init_active_key\n\nWhen it returns an error from sctp_auth_asoc_init_active_key(), the\nactive_key is actually not updated. The old sh_key will be freeed\nwhile it's still used as active key in asoc. Then an use-after-free\nwill be triggered when sending patckets, as found by syzbot:\n\n  sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112\n  sctp_set_owner_w net/sctp/socket.c:132 [inline]\n  sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863\n  sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025\n  inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819\n  sock_sendmsg_nosec net/socket.c:714 [inline]\n  sock_sendmsg+0xcf/0x120 net/socket.c:734\n\nThis patch is to fix it by not replacing the sh_key when it returns\nerrors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key().\nFor sctp_auth_set_active_key(), old active_key_id will be set back\nto asoc->active_key_id when the same thing happens.(CVE-2022-50243)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nigb: Do not free q_vector unless new one was allocated\n\nAvoid potential use-after-free condition under memory pressure. If the\nkzalloc() fails, q_vector will be freed but left in the original\nadapter->q_vector[v_idx] array position.(CVE-2022-50252)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds()\n\nThis patch fixes a stack-out-of-bounds read in brcmfmac that occurs\nwhen 'buf' that is not null-terminated is passed as an argument of\nstrsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware\nversion string by memcpy() in brcmf_fil_iovar_data_get().\nThe patch ensures buf is null-terminated.\n\nFound by a modified version of syzkaller.\n\n[   47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3\n[   47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available\n[   47.601565][ T1897] ==================================================================\n[   47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0\n[   47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897\n[   47.604336][ T1897]\n[   47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G           O      5.14.0+ #131\n[   47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\n[   47.606907][ T1897] Workqueue: usb_hub_wq hub_event\n[   47.607453][ T1897] Call Trace:\n[   47.607801][ T1897]  dump_stack_lvl+0x8e/0xd1\n[   47.608295][ T1897]  print_address_description.constprop.0.cold+0xf/0x334\n[   47.609009][ T1897]  ? strsep+0x1b2/0x1f0\n[   47.609434][ T1897]  ? strsep+0x1b2/0x1f0\n[   47.609863][ T1897]  kasan_report.cold+0x83/0xdf\n[   47.610366][ T1897]  ? strsep+0x1b2/0x1f0\n[   47.610882][ T1897]  strsep+0x1b2/0x1f0\n[   47.611300][ T1897]  ? brcmf_fil_iovar_data_get+0x3a/0xf0\n[   47.611883][ T1897]  brcmf_c_preinit_dcmds+0x995/0xc40\n[   47.612434][ T1897]  ? brcmf_c_set_joinpref_default+0x100/0x100\n[   47.613078][ T1897]  ? rcu_read_lock_sched_held+0xa1/0xd0\n[   47.613662][ T1897]  ? rcu_read_lock_bh_held+0xb0/0xb0\n[   47.614208][ T1897]  ? lock_acquire+0x19d/0x4e0\n[   47.614704][ T1897]  ? find_held_lock+0x2d/0x110\n[   47.615236][ T1897]  ? brcmf_usb_deq+0x1a7/0x260\n[   47.615741][ T1897]  ? brcmf_usb_rx_fill_all+0x5a/0xf0\n[   47.616288][ T1897]  brcmf_attach+0x246/0xd40\n[   47.616758][ T1897]  ? wiphy_new_nm+0x1703/0x1dd0\n[   47.617280][ T1897]  ? kmemdup+0x43/0x50\n[   47.617720][ T1897]  brcmf_usb_probe+0x12de/0x1690\n[   47.618244][ T1897]  ? brcmf_usbdev_qinit.constprop.0+0x470/0x470\n[   47.618901][ T1897]  usb_probe_interface+0x2aa/0x760\n[   47.619429][ T1897]  ? usb_probe_device+0x250/0x250\n[   47.619950][ T1897]  really_probe+0x205/0xb70\n[   47.620435][ T1897]  ? driver_allows_async_probing+0x130/0x130\n[   47.621048][ T1897]  __driver_probe_device+0x311/0x4b0\n[   47.621595][ T1897]  ? driver_allows_async_probing+0x130/0x130\n[   47.622209][ T1897]  driver_probe_device+0x4e/0x150\n[   47.622739][ T1897]  __device_attach_driver+0x1cc/0x2a0\n[   47.623287][ T1897]  bus_for_each_drv+0x156/0x1d0\n[   47.623796][ T1897]  ? bus_rescan_devices+0x30/0x30\n[   47.624309][ T1897]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n[   47.624907][ T1897]  ? trace_hardirqs_on+0x46/0x160\n[   47.625437][ T1897]  __device_attach+0x23f/0x3a0\n[   47.625924][ T1897]  ? device_bind_driver+0xd0/0xd0\n[   47.626433][ T1897]  ? kobject_uevent_env+0x287/0x14b0\n[   47.627057][ T1897]  bus_probe_device+0x1da/0x290\n[   47.627557][ T1897]  device_add+0xb7b/0x1eb0\n[   47.628027][ T1897]  ? wait_for_completion+0x290/0x290\n[   47.628593][ T1897]  ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0\n[   47.629249][ T1897]  usb_set_configuration+0xf59/0x16f0\n[   47.629829][ T1897]  usb_generic_driver_probe+0x82/0xa0\n[   47.630385][ T1897]  usb_probe_device+0xbb/0x250\n[   47.630927][ T1897]  ? usb_suspend+0x590/0x590\n[   47.631397][ T1897]  really_probe+0x205/0xb70\n[   47.631855][ T1897]  ? driver_allows_async_probing+0x130/0x130\n[   47.632469][ T1897]  __driver_probe_device+0x311/0x4b0\n[   47.633002][ \n---truncated---(CVE-2022-50258)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: fix potential memory leak in brcmf_netdev_start_xmit()\n\nThe brcmf_netdev_start_xmit() returns NETDEV_TX_OK without freeing skb\nin case of pskb_expand_head() fails, add dev_kfree_skb() to fix it.\nCompile tested only.(CVE-2022-50321)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix a null-ptr-deref in tipc_topsrv_accept\n\nsyzbot found a crash in tipc_topsrv_accept:\n\n  KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n  Workqueue: tipc_rcv tipc_topsrv_accept\n  RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487\n  Call Trace:\n   <TASK>\n   tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460\n   process_one_work+0x991/0x1610 kernel/workqueue.c:2289\n   worker_thread+0x665/0x1080 kernel/workqueue.c:2436\n   kthread+0x2e4/0x3a0 kernel/kthread.c:376\n   ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n\nIt was caused by srv->listener that might be set to null by\ntipc_topsrv_stop() in net .exit whereas it's still used in\ntipc_topsrv_accept() worker.\n\nsrv->listener is protected by srv->idr_lock in tipc_topsrv_stop(), so add\na check for srv->listener under srv->idr_lock in tipc_topsrv_accept() to\navoid the null-ptr-deref. To ensure the lsock is not released during the\ntipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop()\nwhere it's waiting until the tipc_topsrv_accept worker to be done.\n\nNote that sk_callback_lock is used to protect sk->sk_user_data instead of\nsrv->listener, and it should check srv in tipc_topsrv_listener_data_ready()\ninstead. This also ensures that no more tipc_topsrv_accept worker will be\nstarted after tipc_conn_close() is called in tipc_topsrv_stop() where it\nsets sk->sk_user_data to null.(CVE-2022-50555)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nigb: Fix igb_down hung on surprise removal\n\nIn a setup where a Thunderbolt hub connects to Ethernet and a display\nthrough USB Type-C, users may experience a hung task timeout when they\nremove the cable between the PC and the Thunderbolt hub.\nThis is because the igb_down function is called multiple times when\nthe Thunderbolt hub is unplugged. For example, the igb_io_error_detected\ntriggers the first call, and the igb_remove triggers the second call.\nThe second call to igb_down will block at napi_synchronize.\nHere's the call trace:\n    __schedule+0x3b0/0xddb\n    ? __mod_timer+0x164/0x5d3\n    schedule+0x44/0xa8\n    schedule_timeout+0xb2/0x2a4\n    ? run_local_timers+0x4e/0x4e\n    msleep+0x31/0x38\n    igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4]\n    __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4]\n    igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4]\n    __dev_close_many+0x95/0xec\n    dev_close_many+0x6e/0x103\n    unregister_netdevice_many+0x105/0x5b1\n    unregister_netdevice_queue+0xc2/0x10d\n    unregister_netdev+0x1c/0x23\n    igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4]\n    pci_device_remove+0x3f/0x9c\n    device_release_driver_internal+0xfe/0x1b4\n    pci_stop_bus_device+0x5b/0x7f\n    pci_stop_bus_device+0x30/0x7f\n    pci_stop_bus_device+0x30/0x7f\n    pci_stop_and_remove_bus_device+0x12/0x19\n    pciehp_unconfigure_device+0x76/0xe9\n    pciehp_disable_slot+0x6e/0x131\n    pciehp_handle_presence_or_link_change+0x7a/0x3f7\n    pciehp_ist+0xbe/0x194\n    irq_thread_fn+0x22/0x4d\n    ? irq_thread+0x1fd/0x1fd\n    irq_thread+0x17b/0x1fd\n    ? irq_forced_thread_fn+0x5f/0x5f\n    kthread+0x142/0x153\n    ? __irq_get_irqchip_state+0x46/0x46\n    ? kthread_associate_blkcg+0x71/0x71\n    ret_from_fork+0x1f/0x30\n\nIn this case, igb_io_error_detected detaches the network interface\nand requests a PCIE slot reset, however, the PCIE reset callback is\nnot being invoked and thus the Ethernet connection breaks down.\nAs the PCIE error in this case is a non-fatal one, requesting a\nslot reset can be avoided.\nThis patch fixes the task hung issue and preserves Ethernet\nconnection by ignoring non-fatal PCIE errors.(CVE-2023-53148)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: Fix use after free for wext\n\nKey information in wext.connect is not reset on (re)connect and can hold\ndata from a previous connection.\n\nReset key data to avoid that drivers or mac80211 incorrectly detect a\nWEP connection request and access the freed or already reused memory.\n\nAdditionally optimize cfg80211_sme_connect() and avoid an useless\nschedule of conn_work.(CVE-2023-53153)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: jfs_dmap: Validate db_l2nbperpage while mounting\n\nIn jfs_dmap.c at line 381, BLKTODMAP is used to get a logical block\nnumber inside dbFree(). db_l2nbperpage, which is the log2 number of\nblocks per page, is passed as an argument to BLKTODMAP which uses it\nfor shifting.\n\nSyzbot reported a shift out-of-bounds crash because db_l2nbperpage is\ntoo big. This happens because the large value is set without any\nvalidation in dbMount() at line 181.\n\nThus, make sure that db_l2nbperpage is correct while mounting.\n\nMax number of blocks per page = Page size / Min block size\n=> log2(Max num_block per page) = log2(Page size / Min block size)\n\t\t\t\t= log2(Page size) - log2(Min block size)\n\n=> Max db_l2nbperpage = L2PSIZE - L2MINBLOCKSIZE(CVE-2023-53222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime\n\nAssuming the "rx-vlan-filter" feature is enabled on a net device, the\n8021q module will automatically add or remove VLAN 0 when the net device\nis put administratively up or down, respectively. There are a couple of\nproblems with the above scheme.\n\nThe first problem is a memory leak that can happen if the "rx-vlan-filter"\nfeature is disabled while the device is running:\n\n # ip link add bond1 up type bond mode 0\n # ethtool -K bond1 rx-vlan-filter off\n # ip link del dev bond1\n\nWhen the device is put administratively down the "rx-vlan-filter"\nfeature is disabled, so the 8021q module will not remove VLAN 0 and the\nmemory will be leaked [1].\n\nAnother problem that can happen is that the kernel can automatically\ndelete VLAN 0 when the device is put administratively down despite not\nadding it when the device was put administratively up since during that\ntime the "rx-vlan-filter" feature was disabled. null-ptr-unref or\nbug_on[2] will be triggered by unregister_vlan_dev() for refcount\nimbalance if toggling filtering during runtime:\n\n$ ip link add bond0 type bond mode 0\n$ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q\n$ ethtool -K bond0 rx-vlan-filter off\n$ ifconfig bond0 up\n$ ethtool -K bond0 rx-vlan-filter on\n$ ifconfig bond0 down\n$ ip link del vlan0\n\nRoot cause is as below:\nstep1: add vlan0 for real_dev, such as bond, team.\nregister_vlan_dev\n    vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1\nstep2: disable vlan filter feature and enable real_dev\nstep3: change filter from 0 to 1\nvlan_device_event\n    vlan_filter_push_vids\n        ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0\nstep4: real_dev down\nvlan_device_event\n    vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0\n        vlan_info_rcu_free //free vlan0\nstep5: delete vlan0\nunregister_vlan_dev\n    BUG_ON(!vlan_info); //vlan_info is null\n\nFix both problems by noting in the VLAN info whether VLAN 0 was\nautomatically added upon NETDEV_UP and based on that decide whether it\nshould be deleted upon NETDEV_DOWN, regardless of the state of the\n"rx-vlan-filter" feature.\n\n[1]\nunreferenced object 0xffff8880068e3100 (size 256):\n  comm "ip", pid 384, jiffies 4296130254\n  hex dump (first 32 bytes):\n    00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00  . 0.............\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace (crc 81ce31fa):\n    __kmalloc_cache_noprof+0x2b5/0x340\n    vlan_vid_add+0x434/0x940\n    vlan_device_event.cold+0x75/0xa8\n    notifier_call_chain+0xca/0x150\n    __dev_notify_flags+0xe3/0x250\n    rtnl_configure_link+0x193/0x260\n    rtnl_newlink_create+0x383/0x8e0\n    __rtnl_newlink+0x22c/0xa40\n    rtnl_newlink+0x627/0xb00\n    rtnetlink_rcv_msg+0x6fb/0xb70\n    netlink_rcv_skb+0x11f/0x350\n    netlink_unicast+0x426/0x710\n    netlink_sendmsg+0x75a/0xc20\n    __sock_sendmsg+0xc1/0x150\n    ____sys_sendmsg+0x5aa/0x7b0\n    ___sys_sendmsg+0xfc/0x180\n\n[2]\nkernel BUG at net/8021q/vlan.c:99!\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\nBIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))\nRSP: 0018:ffff88810badf310 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8\nRBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80\nR10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000\nR13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e\nFS:  00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0\nCall Trace:\n <TASK\n---truncated---(CVE-2025-38470)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: fix a race in packet_set_ring() and packet_notifier()\n\nWhen packet_set_ring() releases po->bind_lock, another thread can\nrun packet_notifier() and process an NETDEV_UP event.\n\nThis race and the fix are both similar to that of commit 15fe076edea7\n("net/packet: fix a race in packet_bind() and packet_notifier()").\n\nThere too the packet_notifier NETDEV_UP event managed to run while a\npo->bind_lock critical section had to be temporarily released. And\nthe fix was similarly to temporarily set po->num to zero to keep\nthe socket unhooked until the lock is retaken.\n\nThe po->bind_lock in packet_set_ring and packet_notifier precede the\nintroduction of git history.(CVE-2025-38617)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2512.1.0.0354.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm","kernel-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm","perf-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2512.1.0.0354.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm","kernel-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm","perf-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2805"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50243"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50252"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50258"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50321"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50555"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53148"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53153"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53222"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38470"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38617"}],"database_specific":{"severity":"High"}}