{"schema_version":"1.7.2","id":"OESA-2026-1229","modified":"2026-01-23T12:23:54Z","published":"2026-01-23T12:23:54Z","upstream":["CVE-2024-53685","CVE-2024-58241","CVE-2025-21652","CVE-2025-37777","CVE-2025-37928","CVE-2025-37985","CVE-2025-38008","CVE-2025-38436","CVE-2025-38501","CVE-2025-39673","CVE-2025-39835","CVE-2025-39925","CVE-2025-68301"],"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\nceph: give up on paths longer than PATH_MAX\n\nIf the full path to be built by ceph_mdsc_build_path() happens to be\nlonger than PATH_MAX, then this function will enter an endless (retry)\nloop, effectively blocking the whole task.  Most of the machine\nbecomes unusable, making this a very simple and effective DoS\nvulnerability.\n\nI cannot imagine why this retry was ever implemented, but it seems\nrather useless and harmful to me.  Let's remove it and fail with\nENAMETOOLONG instead.(CVE-2024-53685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: Disable works on hci_unregister_dev\n\nThis make use of disable_work_* on hci_unregister_dev since the hci_dev is\nabout to be freed new submissions are not disarable.(CVE-2024-58241)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvlan: Fix use-after-free in ipvlan_get_iflink().\n\nsyzbot presented an use-after-free report [0] regarding ipvlan and\nlinkwatch.\n\nipvlan does not hold a refcnt of the lower device unlike vlan and\nmacvlan.\n\nIf the linkwatch work is triggered for the ipvlan dev, the lower dev\nmight have already been freed, resulting in UAF of ipvlan->phy_dev in\nipvlan_get_iflink().\n\nWe can delay the lower dev unregistration like vlan and macvlan by\nholding the lower dev's refcnt in dev->netdev_ops->ndo_init() and\nreleasing it in dev->priv_destructor().\n\nJakub pointed out calling .ndo_XXX after unregister_netdevice() has\nreturned is error prone and suggested [1] addressing this UAF in the\ncore by taking commit 750e51603395 ("net: avoid potential UAF in\ndefault_operstate()") further.\n\nLet's assume unregistering devices DOWN and use RCU protection in\ndefault_operstate() not to race with the device unregistration.\n\n[0]:\nBUG: KASAN: slab-use-after-free in ipvlan_get_iflink+0x84/0x88 drivers/net/ipvlan/ipvlan_main.c:353\nRead of size 4 at addr ffff0000d768c0e0 by task kworker/u8:35/6944\n\nCPU: 0 UID: 0 PID: 6944 Comm: kworker/u8:35 Not tainted 6.13.0-rc2-g9bc5c9515b48 #12 4c3cb9e8b4565456f6a355f312ff91f4f29b3c47\nHardware name: linux,dummy-virt (DT)\nWorkqueue: events_unbound linkwatch_event\nCall trace:\n show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:484 (C)\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x16c/0x6f0 mm/kasan/report.c:489\n kasan_report+0xc0/0x120 mm/kasan/report.c:602\n __asan_report_load4_noabort+0x20/0x30 mm/kasan/report_generic.c:380\n ipvlan_get_iflink+0x84/0x88 drivers/net/ipvlan/ipvlan_main.c:353\n dev_get_iflink+0x7c/0xd8 net/core/dev.c:674\n default_operstate net/core/link_watch.c:45 [inline]\n rfc2863_policy+0x144/0x360 net/core/link_watch.c:72\n linkwatch_do_dev+0x60/0x228 net/core/link_watch.c:175\n __linkwatch_run_queue+0x2f4/0x5b8 net/core/link_watch.c:239\n linkwatch_event+0x64/0xa8 net/core/link_watch.c:282\n process_one_work+0x700/0x1398 kernel/workqueue.c:3229\n process_scheduled_works kernel/workqueue.c:3310 [inline]\n worker_thread+0x8c4/0xe10 kernel/workqueue.c:3391\n kthread+0x2b0/0x360 kernel/kthread.c:389\n ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:862\n\nAllocated by task 9303:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x30/0x68 mm/kasan/common.c:68\n kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4283 [inline]\n __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4289\n __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:650\n alloc_netdev_mqs+0xb4/0x1118 net/core/dev.c:11209\n rtnl_create_link+0x2b8/0xb60 net/core/rtnetlink.c:3595\n rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3771\n __rtnl_newlink net/core/rtnetlink.c:3896 [inline]\n rtnl_newlink+0x122c/0x15c0 net/core/rtnetlink.c:4011\n rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6901\n netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2542\n rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6928\n netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]\n netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1347\n netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1891\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg net/socket.c:726 [inline]\n __sys_sendto+0x2ec/0x438 net/socket.c:2197\n __do_sys_sendto net/socket.c:2204 [inline]\n __se_sys_sendto net/socket.c:2200 [inline]\n __arm64_sys_sendto+0xe4/0x110 net/socket.c:2200\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151\n el\n---truncated---(CVE-2025-21652)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in __smb2_lease_break_noti()\n\nMove tcp_transport free to ksmbd_conn_free. If ksmbd connection is\nreferenced when ksmbd server thread terminates, It will not be freed,\nbut conn->tcp_transport is freed. __smb2_lease_break_noti can be performed\nasynchronously when the connection is disconnected. __smb2_lease_break_noti\ncalls ksmbd_conn_write, which can cause use-after-free\nwhen conn->ksmbd_transport is already freed.(CVE-2025-37777)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm-bufio: don't schedule in atomic context\n\nA BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP and\ntry_verify_in_tasklet are enabled.\n[  129.444685][  T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421\n[  129.444723][  T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4\n[  129.444740][  T934] preempt_count: 201, expected: 0\n[  129.444756][  T934] RCU nest depth: 0, expected: 0\n[  129.444781][  T934] Preemption disabled at:\n[  129.444789][  T934] [<ffffffd816231900>] shrink_work+0x21c/0x248\n[  129.445167][  T934] kernel BUG at kernel/sched/walt/walt_debug.c:16!\n[  129.445183][  T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\n[  129.445204][  T934] Skip md ftrace buffer dump for: 0x1609e0\n[  129.447348][  T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G        W  OE      6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8\n[  129.447362][  T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT)\n[  129.447373][  T934] Workqueue: dm_bufio_cache shrink_work\n[  129.447394][  T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  129.447406][  T934] pc : android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug]\n[  129.447435][  T934] lr : __traceiter_android_rvh_schedule_bug+0x44/0x6c\n[  129.447451][  T934] sp : ffffffc0843dbc90\n[  129.447459][  T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b\n[  129.447479][  T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68\n[  129.447497][  T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900\n[  129.447517][  T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030\n[  129.447535][  T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358\n[  129.447554][  T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003\n[  129.447572][  T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400\n[  129.447591][  T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8\n[  129.447610][  T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0\n[  129.447629][  T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000\n[  129.447647][  T934] Call trace:\n[  129.447655][  T934]  android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6]\n[  129.447681][  T934]  __might_resched+0x190/0x1a8\n[  129.447694][  T934]  shrink_work+0x180/0x248\n[  129.447706][  T934]  process_one_work+0x260/0x624\n[  129.447718][  T934]  worker_thread+0x28c/0x454\n[  129.447729][  T934]  kthread+0x118/0x158\n[  129.447742][  T934]  ret_from_fork+0x10/0x20\n[  129.447761][  T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000)\n[  129.447772][  T934] ---[ end trace 0000000000000000 ]---\n\ndm_bufio_lock will call spin_lock_bh when try_verify_in_tasklet\nis enabled, and __scan will be called in atomic context.(CVE-2025-37928)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: wdm: close race between wdm_open and wdm_wwan_port_stop\n\nClearing WDM_WWAN_IN_USE must be the last action or\nwe can open a chardev whose URBs are still poisoned(CVE-2025-37985)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: fix race condition in unaccepted memory handling\n\nThe page allocator tracks the number of zones that have unaccepted memory\nusing static_branch_enc/dec() and uses that static branch in hot paths to\ndetermine if it needs to deal with unaccepted memory.\n\nBorislav and Thomas pointed out that the tracking is racy: operations on\nstatic_branch are not serialized against adding/removing unaccepted pages\nto/from the zone.\n\nSanity checks inside static_branch machinery detects it:\n\nWARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0\n\nThe comment around the WARN() explains the problem:\n\n\t/*\n\t * Warn about the '-1' case though; since that means a\n\t * decrement is concurrent with a first (0->1) increment. IOW\n\t * people are trying to disable something that wasn't yet fully\n\t * enabled. This suggests an ordering problem on the user side.\n\t */\n\nThe effect of this static_branch optimization is only visible on\nmicrobenchmark.\n\nInstead of adding more complexity around it, remove it altogether.(CVE-2025-38008)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/scheduler: signal scheduled fence when kill job\n\nWhen an entity from application B is killed, drm_sched_entity_kill()\nremoves all jobs belonging to that entity through\ndrm_sched_entity_kill_jobs_work(). If application A's job depends on a\nscheduled fence from application B's job, and that fence is not properly\nsignaled during the killing process, application A's dependency cannot be\ncleared.\n\nThis leads to application A hanging indefinitely while waiting for a\ndependency that will never be resolved. Fix this issue by ensuring that\nscheduled fences are properly signaled when an entity is killed, allowing\ndependent applications to continue execution.(CVE-2025-38436)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: limit repeated connections from clients with the same IP\n\nRepeated connections from clients with the same IP address may exhaust\nthe max connections and prevent other normal client connections.\nThis patch limit repeated connections from clients with the same IP.(CVE-2025-38501)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: fix race conditions in ppp_fill_forward_path\n\nppp_fill_forward_path() has two race conditions:\n\n1. The ppp->channels list can change between list_empty() and\n   list_first_entry(), as ppp_lock() is not held. If the only channel\n   is deleted in ppp_disconnect_channel(), list_first_entry() may\n   access an empty head or a freed entry, and trigger a panic.\n\n2. pch->chan can be NULL. When ppp_unregister_channel() is called,\n   pch->chan is set to NULL before pch is removed from ppp->channels.\n\nFix these by using a lockless RCU approach:\n- Use list_first_or_null_rcu() to safely test and access the first list\n  entry.\n- Convert list modifications on ppp->channels to their RCU variants and\n  add synchronize_net() after removal.\n- Check for a NULL pch->chan before dereferencing it.(CVE-2025-39673)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: do not propagate ENODATA disk errors into xattr code\n\nENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code;\nnamely, that the requested attribute name could not be found.\n\nHowever, a medium error from disk may also return ENODATA. At best,\nthis medium error may escape to userspace as "attribute not found"\nwhen in fact it's an IO (disk) error.\n\nAt worst, we may oops in xfs_attr_leaf_get() when we do:\n\n\terror = xfs_attr_leaf_hasname(args, &bp);\n\tif (error == -ENOATTR)  {\n\t\txfs_trans_brelse(args->trans, bp);\n\t\treturn error;\n\t}\n\nbecause an ENODATA/ENOATTR error from disk leaves us with a null bp,\nand the xfs_trans_brelse will then null-deref it.\n\nAs discussed on the list, we really need to modify the lower level\nIO functions to trap all disk errors and ensure that we don't let\nunique errors like this leak up into higher xfs functions - many\nlike this should be remapped to EIO.\n\nHowever, this patch directly addresses a reported bug in the xattr\ncode, and should be safe to backport to stable kernels. A larger-scope\npatch to handle more unique errors at lower levels can follow later.\n\n(Note, prior to 07120f1abdff we did not oops, but we did return the\nwrong error code to userspace.)(CVE-2025-39835)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: j1939: implement NETDEV_UNREGISTER notification handler\n\nsyzbot is reporting\n\n  unregister_netdevice: waiting for vcan0 to become free. Usage count = 2\n\nproblem, for j1939 protocol did not have NETDEV_UNREGISTER notification\nhandler for undoing changes made by j1939_sk_bind().\n\nCommit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct\ncallback") expects that a call to j1939_priv_put() can be unconditionally\ndelayed until j1939_sk_sock_destruct() is called. But we need to call\nj1939_priv_put() against an extra ref held by j1939_sk_bind() call\n(as a part of undoing changes made by j1939_sk_bind()) as soon as\nNETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct()\nis called via j1939_sk_release()). Otherwise, the extra ref on "struct\nj1939_priv" held by j1939_sk_bind() call prevents "struct net_device" from\ndropping the usage count to 1; making it impossible for\nunregister_netdevice() to continue.\n\n[mkl: remove space in front of label](CVE-2025-39925)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: atlantic: fix fragment overflow handling in RX path\n\nThe atlantic driver can receive packets with more than MAX_SKB_FRAGS (17)\nfragments when handling large multi-descriptor packets. This causes an\nout-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic.\n\nThe issue occurs because the driver doesn't check the total number of\nfragments before calling skb_add_rx_frag(). When a packet requires more\nthan MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds.\n\nFix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE,\nthen all fragments are accounted for. And reusing the existing check to\nprevent the overflow earlier in the code path.\n\nThis crash occurred in production with an Aquantia AQC113 10G NIC.\n\nStack trace from production environment:\n```\nRIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0\nCode: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89\nca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90\nc8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48\n89 fa 83\nRSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287\nRAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:\nfffffffe0a0c8000\nRDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:\n0000000000037a40\nRBP: 0000000000000024 R08: 0000000000000000 R09:\n0000000000000021\nR10: 0000000000000848 R11: 0000000000000000 R12:\nffffa9bec02a8e24\nR13: ffff925ad8615570 R14: 0000000000000000 R15:\nffff925b22e80a00\nFS: 0000000000000000(0000)\nGS:ffff925e47880000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:\n0000000000f72ef0\nPKRU: 55555554\nCall Trace:\n<IRQ>\naq_ring_rx_clean+0x175/0xe60 [atlantic]\n? aq_ring_rx_clean+0x14d/0xe60 [atlantic]\n? aq_ring_tx_clean+0xdf/0x190 [atlantic]\n? kmem_cache_free+0x348/0x450\n? aq_vec_poll+0x81/0x1d0 [atlantic]\n? __napi_poll+0x28/0x1c0\n? net_rx_action+0x337/0x420\n```\n\nChanges in v4:\n- Add Fixes: tag to satisfy patch validation requirements.\n\nChanges in v3:\n- Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE,\n  then all fragments are accounted for.(CVE-2025-68301)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-135.0.0.129.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-135.0.0.129.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-135.0.0.129.oe2403sp1.aarch64.rpm","kernel-6.6.0-135.0.0.129.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-135.0.0.129.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-135.0.0.129.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-135.0.0.129.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-135.0.0.129.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-135.0.0.129.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-135.0.0.129.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-135.0.0.129.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-135.0.0.129.oe2403sp1.aarch64.rpm","perf-6.6.0-135.0.0.129.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-135.0.0.129.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-135.0.0.129.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-135.0.0.129.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-135.0.0.129.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-135.0.0.129.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-135.0.0.129.oe2403sp1.x86_64.rpm","kernel-6.6.0-135.0.0.129.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-135.0.0.129.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-135.0.0.129.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-135.0.0.129.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-135.0.0.129.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-135.0.0.129.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-135.0.0.129.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-135.0.0.129.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-135.0.0.129.oe2403sp1.x86_64.rpm","perf-6.6.0-135.0.0.129.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-135.0.0.129.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-135.0.0.129.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-135.0.0.129.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1229"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53685"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58241"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21652"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37777"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37928"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37985"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38008"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38436"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38501"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39673"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39835"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39925"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68301"}],"database_specific":{"severity":"High"}}