{"schema_version":"1.7.2","id":"OESA-2025-1629","modified":"2025-06-13T14:20:13Z","published":"2025-06-13T14:20:13Z","upstream":["CVE-2024-47716","CVE-2024-58100","CVE-2025-21872","CVE-2025-21925","CVE-2025-21966","CVE-2025-22126","CVE-2025-23131","CVE-2025-23148","CVE-2025-23156","CVE-2025-37857","CVE-2025-37916","CVE-2025-37921","CVE-2025-37923","CVE-2025-37926","CVE-2025-37958","CVE-2025-37969","CVE-2025-37995","CVE-2025-40325"],"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\nARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros\n\nFloating point instructions in userspace can crash some arm kernels\nbuilt with clang/LLD 17.0.6:\n\n    BUG: unsupported FP instruction in kernel mode\n    FPEXC == 0xc0000780\n    Internal error: Oops - undefined instruction: 0 [#1] ARM\n    CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1\n    Hardware name: BCM2835\n    PC is at vfp_support_entry+0xc8/0x2cc\n    LR is at do_undefinstr+0xa8/0x250\n    pc : [\u0026lt;c0101d50\u0026gt;]    lr : [\u0026lt;c010a80c\u0026gt;]    psr: a0000013\n    sp : dc8d1f68  ip : 60000013  fp : bedea19c\n    r10: ec532b17  r9 : 00000010  r8 : 0044766c\n    r7 : c0000780  r6 : ec532b17  r5 : c1c13800  r4 : dc8d1fb0\n    r3 : c10072c4  r2 : c0101c88  r1 : ec532b17  r0 : 0044766c\n    Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none\n    Control: 00c5387d  Table: 0251c008  DAC: 00000051\n    Register r0 information: non-paged memory\n    Register r1 information: vmalloc memory\n    Register r2 information: non-slab/vmalloc memory\n    Register r3 information: non-slab/vmalloc memory\n    Register r4 information: 2-page vmalloc region\n    Register r5 information: slab kmalloc-cg-2k\n    Register r6 information: vmalloc memory\n    Register r7 information: non-slab/vmalloc memory\n    Register r8 information: non-paged memory\n    Register r9 information: zero-size pointer\n    Register r10 information: vmalloc memory\n    Register r11 information: non-paged memory\n    Register r12 information: non-paged memory\n    Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b)\n    Stack: (0xdc8d1f68 to 0xdc8d2000)\n    1f60:                   0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0\n    1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010\n    1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188\n    1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c\n    1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000\n    Call trace:\n    [\u0026lt;c0101d50\u0026gt;] (vfp_support_entry) from [\u0026lt;c010a80c\u0026gt;] (do_undefinstr+0xa8/0x250)\n    [\u0026lt;c010a80c\u0026gt;] (do_undefinstr) from [\u0026lt;c0100f10\u0026gt;] (__und_usr+0x70/0x80)\n    Exception stack(0xdc8d1fb0 to 0xdc8d1ff8)\n    1fa0:                                     b6f68af8 00448fc0 00000000 bedea188\n    1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c\n    1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff\n    Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10)\n    ---[ end trace 0000000000000000 ]---\n    Kernel panic - not syncing: Fatal exception in interrupt\n    ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---\n\nThis is a minimal userspace reproducer on a Raspberry Pi Zero W:\n\n    #include \u0026lt;stdio.h\u0026gt;\n    #include \u0026lt;math.h\u0026gt;\n\n    int main(void)\n    {\n            double v = 1.0;\n            printf(\u0026quot;%fn\u0026quot;, NAN + *(volatile double *)\u0026amp;v);\n            return 0;\n    }\n\nAnother way to consistently trigger the oops is:\n\n    calvin@raspberry-pi-zero-w ~$ python -c \u0026quot;import json\u0026quot;\n\nThe bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n,\nbecause the pr_debug() calls act as barriers even when not activated.\n\nThis is the output from the same kernel source built with the same\ncompiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as\nexpected:\n\n    VFP: bounce: trigger ec532b17 fpexc c0000780\n    VFP: emulate: INST=0xee377b06 SCR=0x00000000\n    VFP: bounce: trigger eef1fa10 fpexc c0000780\n    VFP: emulate: INST=0xeeb40b40 SCR=0x00000000\n    VFP: raising exceptions 30000000\n\n    calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer\n    nan\n\nCrudely grepping for vmsr/vmrs instructions in the otherwise nearly\nidential text for vfp_support_entry() makes the problem obvious:\n\n    vmlinux.llvm.good [0xc0101cb8] \u0026lt;+48\u0026gt;:  vmrs   r7, fpexc\n    vmlinux.llvm.good [0xc0101cd8] \u0026lt;+80\u0026gt;:  vmsr   fpexc, r0\n    vmlinux.llvm.good [0xc0101d20\n---truncated---(CVE-2024-47716)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: check changes_pkt_data property for extension programs\n\nWhen processing calls to global sub-programs, verifier decides whether\nto invalidate all packet pointers in current state depending on the\nchanges_pkt_data property of the global sub-program.\n\nBecause of this, an extension program replacing a global sub-program\nmust be compatible with changes_pkt_data property of the sub-program\nbeing replaced.\n\nThis commit:\n- adds changes_pkt_data flag to struct bpf_prog_aux:\n  - this flag is set in check_cfg() for main sub-program;\n  - in jit_subprogs() for other sub-programs;\n- modifies bpf_check_attach_btf_id() to check changes_pkt_data flag;\n- moves call to check_attach_btf_id() after the call to check_cfg(),\n  because it needs changes_pkt_data flag to be set:\n\n    bpf_check:\n      ...                             ...\n    - check_attach_btf_id             resolve_pseudo_ldimm64\n      resolve_pseudo_ldimm64   --\u0026gt;    bpf_prog_is_offloaded\n      bpf_prog_is_offloaded           check_cfg\n      check_cfg                     + check_attach_btf_id\n      ...                             ...\n\nThe following fields are set by check_attach_btf_id():\n- env-\u0026gt;ops\n- prog-\u0026gt;aux-\u0026gt;attach_btf_trace\n- prog-\u0026gt;aux-\u0026gt;attach_func_name\n- prog-\u0026gt;aux-\u0026gt;attach_func_proto\n- prog-\u0026gt;aux-\u0026gt;dst_trampoline\n- prog-\u0026gt;aux-\u0026gt;mod\n- prog-\u0026gt;aux-\u0026gt;saved_dst_attach_type\n- prog-\u0026gt;aux-\u0026gt;saved_dst_prog_type\n- prog-\u0026gt;expected_attach_type\n\nNeither of these fields are used by resolve_pseudo_ldimm64() or\nbpf_prog_offload_verifier_prep() (for netronome and netdevsim\ndrivers), so the reordering is safe.(CVE-2024-58100)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nefi: Don\u0026apos;t map the entire mokvar table to determine its size\n\nCurrently, when validating the mokvar table, we (re)map the entire table\non each iteration of the loop, adding space as we discover new entries.\nIf the table grows over a certain size, this fails due to limitations of\nearly_memmap(), and we get a failure and traceback:\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220\n  ...\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? __early_ioremap+0xef/0x220\n   ? __warn.cold+0x93/0xfa\n   ? __early_ioremap+0xef/0x220\n   ? report_bug+0xff/0x140\n   ? early_fixup_exception+0x5d/0xb0\n   ? early_idt_handler_common+0x2f/0x3a\n   ? __early_ioremap+0xef/0x220\n   ? efi_mokvar_table_init+0xce/0x1d0\n   ? setup_arch+0x864/0xc10\n   ? start_kernel+0x6b/0xa10\n   ? x86_64_start_reservations+0x24/0x30\n   ? x86_64_start_kernel+0xed/0xf0\n   ? common_startup_64+0x13e/0x141\n   \u0026lt;/TASK\u0026gt;\n  ---[ end trace 0000000000000000 ]---\n  mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.\n\nMapping the entire structure isn\u0026apos;t actually necessary, as we don\u0026apos;t ever\nneed more than one entry header mapped at once.\n\nChanges efi_mokvar_table_init() to only map each entry header, not the\nentire table, when determining the table size.  Since we\u0026apos;re not mapping\nany data past the variable name, it also changes the code to enforce\nthat each variable name is NUL terminated, rather than attempting to\nverify it in place.(CVE-2025-21872)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nllc: do not use skb_get() before dev_queue_xmit()\n\nsyzbot is able to crash hosts [1], using llc and devices\nnot supporting IFF_TX_SKB_SHARING.\n\nIn this case, e1000 driver calls eth_skb_pad(), while\nthe skb is shared.\n\nSimply replace skb_get() by skb_clone() in net/llc/llc_s_ac.c\n\nNote that e1000 driver might have an issue with pktgen,\nbecause it does not clear IFF_TX_SKB_SHARING, this is an\northogonal change.\n\nWe need to audit other skb_get() uses in net/llc.\n\n[1]\n\nkernel BUG at net/core/skbuff.c:2178 !\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n RIP: 0010:pskb_expand_head+0x6ce/0x1240 net/core/skbuff.c:2178\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  __skb_pad+0x18a/0x610 net/core/skbuff.c:2466\n  __skb_put_padto include/linux/skbuff.h:3843 [inline]\n  skb_put_padto include/linux/skbuff.h:3862 [inline]\n  eth_skb_pad include/linux/etherdevice.h:656 [inline]\n  e1000_xmit_frame+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000_main.c:3128\n  __netdev_start_xmit include/linux/netdevice.h:5151 [inline]\n  netdev_start_xmit include/linux/netdevice.h:5160 [inline]\n  xmit_one net/core/dev.c:3806 [inline]\n  dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3822\n  sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343\n  __dev_xmit_skb net/core/dev.c:4045 [inline]\n  __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4621\n  dev_queue_xmit include/linux/netdevice.h:3313 [inline]\n  llc_sap_action_send_test_c+0x268/0x320 net/llc/llc_s_ac.c:144\n  llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]\n  llc_sap_next_state net/llc/llc_sap.c:182 [inline]\n  llc_sap_state_process+0x239/0x510 net/llc/llc_sap.c:209\n  llc_ui_sendmsg+0xd0d/0x14e0 net/llc/af_llc.c:993\n  sock_sendmsg_nosec net/socket.c:718 [inline](CVE-2025-21925)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm-flakey: Fix memory corruption in optional corrupt_bio_byte feature\n\nFix memory corruption due to incorrect parameter being passed to bio_init(CVE-2025-21966)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix mddev uaf while iterating all_mddevs list\n\nWhile iterating all_mddevs list from md_notify_reboot() and md_exit(),\nlist_for_each_entry_safe is used, and this can race with deletint the\nnext mddev, causing UAF:\n\nt1:\nspin_lock\n//list_for_each_entry_safe(mddev, n, ...)\n mddev_get(mddev1)\n // assume mddev2 is the next entry\n spin_unlock\n            t2:\n            //remove mddev2\n            ...\n            mddev_free\n            spin_lock\n            list_del\n            spin_unlock\n            kfree(mddev2)\n mddev_put(mddev1)\n spin_lock\n //continue dereference mddev2-\u0026gt;all_mddevs\n\nThe old helper for_each_mddev() actually grab the reference of mddev2\nwhile holding the lock, to prevent from being freed. This problem can be\nfixed the same way, however, the code will be complex.\n\nHence switch to use list_for_each_entry, in this case mddev_put() can free\nthe mddev1 and it\u0026apos;s not safe as well. Refer to md_seq_show(), also factor\nout a helper mddev_put_locked() to fix this problem.(CVE-2025-22126)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndlm: prevent NPD when writing a positive value to event_done\n\ndo_uevent returns the value written to event_done. In case it is a\npositive value, new_lockspace would undo all the work, and lockspace\nwould not be set. __dlm_new_lockspace, however, would treat that\npositive value as a success due to commit 8511a2728ab8 (\u0026quot;dlm: fix use\ncount with multiple joins\u0026quot;).\n\nDown the line, device_create_lockspace would pass that NULL lockspace to\ndlm_find_lockspace_local, leading to a NULL pointer dereference.\n\nTreating such positive values as successes prevents the problem. Given\nthis has been broken for so long, this is unlikely to break userspace\nexpectations.(CVE-2025-23131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()\n\nsoc_dev_attr-\u0026gt;revision could be NULL, thus,\na pointer check is added to prevent potential NULL pointer dereference.\nThis is similar to the fix in commit 3027e7b15b02\n(\u0026quot;ice: Fix some null pointer dereference issues in ice_ptp.c\u0026quot;).\n\nThis issue is found by our static analysis tool.(CVE-2025-23148)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi_parser: refactor hfi packet parsing logic\n\nwords_count denotes the number of words in total payload, while data\npoints to payload of various property within it. When words_count\nreaches last word, data can access memory beyond the total payload. This\ncan lead to OOB access. With this patch, the utility api for handling\nindividual properties now returns the size of data consumed. Accordingly\nremaining bytes are calculated before parsing the payload, thereby\neliminates the OOB access possibilities.(CVE-2025-23156)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: st: Fix array overflow in st_setup()\n\nChange the array size to follow parms size instead of a fixed value.(CVE-2025-37857)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npds_core: remove write-after-free of client_id\n\nA use-after-free error popped up in stress testing:\n\n[Mon Apr 21 21:21:33 2025] BUG: KFENCE: use-after-free write in pdsc_auxbus_dev_del+0xef/0x160 [pds_core]\n[Mon Apr 21 21:21:33 2025] Use-after-free write at 0x000000007013ecd1 (in kfence-#47):\n[Mon Apr 21 21:21:33 2025]  pdsc_auxbus_dev_del+0xef/0x160 [pds_core]\n[Mon Apr 21 21:21:33 2025]  pdsc_remove+0xc0/0x1b0 [pds_core]\n[Mon Apr 21 21:21:33 2025]  pci_device_remove+0x24/0x70\n[Mon Apr 21 21:21:33 2025]  device_release_driver_internal+0x11f/0x180\n[Mon Apr 21 21:21:33 2025]  driver_detach+0x45/0x80\n[Mon Apr 21 21:21:33 2025]  bus_remove_driver+0x83/0xe0\n[Mon Apr 21 21:21:33 2025]  pci_unregister_driver+0x1a/0x80\n\nThe actual device uninit usually happens on a separate thread\nscheduled after this code runs, but there is no guarantee of order\nof thread execution, so this could be a problem.  There\u0026apos;s no\nactual need to clear the client_id at this point, so simply\nremove the offending code.(CVE-2025-37916)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: vnifilter: Fix unlocked deletion of default FDB entry\n\nWhen a VNI is deleted from a VXLAN device in \u0026apos;vnifilter\u0026apos; mode, the FDB\nentry associated with the default remote (assuming one was configured)\nis deleted without holding the hash lock. This is wrong and will result\nin a warning [1] being generated by the lockdep annotation that was\nadded by commit ebe642067455 (\u0026quot;vxlan: Create wrappers for FDB lookup\u0026quot;).\n\nReproducer:\n\n # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1\n # bridge vni add vni 10010 remote 198.51.100.1 dev vx0\n # bridge vni del vni 10010 dev vx0\n\nFix by acquiring the hash lock before the deletion and releasing it\nafterwards. Blame the original commit that introduced the issue rather\nthan the one that exposed it.\n\n[1]\nWARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0\n[...]\nRIP: 0010:vxlan_find_mac+0x17f/0x1a0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __vxlan_fdb_delete+0xbe/0x560\n vxlan_vni_delete_group+0x2ba/0x940\n vxlan_vni_del.isra.0+0x15f/0x580\n vxlan_process_vni_filter+0x38b/0x7b0\n vxlan_vnifilter_process+0x3bb/0x510\n rtnetlink_rcv_msg+0x2f7/0xb70\n netlink_rcv_skb+0x131/0x360\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 __sys_sendmsg+0x121/0x1b0\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-37921)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix oob write in trace_seq_to_buffer()\n\nsyzbot reported this bug:\n==================================================================\nBUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]\nBUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822\nWrite of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260\n\nCPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xc3/0x670 mm/kasan/report.c:521\n kasan_report+0xe0/0x110 mm/kasan/report.c:634\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189\n __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106\n trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]\n tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822\n ....\n==================================================================\n\nIt has been reported that trace_seq_to_buffer() tries to copy more data\nthan PAGE_SIZE to buf. Therefore, to prevent this, we should use the\nsmaller of trace_seq_used(\u0026amp;iter-\u0026gt;seq) and PAGE_SIZE as an argument.(CVE-2025-37923)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in ksmbd_session_rpc_open\n\nA UAF issue can occur due to a race condition between\nksmbd_session_rpc_open() and __session_rpc_close().\nAdd rpc_lock to the session to protect it.(CVE-2025-37926)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: fix dereferencing invalid pmd migration entry\n\nWhen migrating a THP, concurrent access to the PMD migration entry during\na deferred split scan can lead to an invalid address access, as\nillustrated below.  To prevent this invalid access, it is necessary to\ncheck the PMD migration entry and return early.  In this context, there is\nno need to use pmd_to_swp_entry and pfn_swap_entry_to_page to verify the\nequality of the target folio.  Since the PMD migration entry is locked, it\ncannot be served as the target.\n\nMailing list discussion and explanation from Hugh Dickins: \u0026quot;An anon_vma\nlookup points to a location which may contain the folio of interest, but\nmight instead contain another folio: and weeding out those other folios is\nprecisely what the \u0026quot;folio != pmd_folio((*pmd)\u0026quot; check (and the \u0026quot;risk of\nreplacing the wrong folio\u0026quot; comment a few lines above it) is for.\u0026quot;\n\nBUG: unable to handle page fault for address: ffffea60001db008\nCPU: 0 UID: 0 PID: 2199114 Comm: tee Not tainted 6.14.0+ #4 NONE\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nRIP: 0010:split_huge_pmd_locked+0x3b5/0x2b60\nCall Trace:\n\u0026lt;TASK\u0026gt;\ntry_to_migrate_one+0x28c/0x3730\nrmap_walk_anon+0x4f6/0x770\nunmap_folio+0x196/0x1f0\nsplit_huge_page_to_list_to_order+0x9f6/0x1560\ndeferred_split_scan+0xac5/0x12a0\nshrinker_debugfs_scan_write+0x376/0x470\nfull_proxy_write+0x15c/0x220\nvfs_write+0x2fc/0xcb0\nksys_write+0x146/0x250\ndo_syscall_64+0x6a/0x120\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe bug is found by syzkaller on an internal kernel, then confirmed on\nupstream.(CVE-2025-37958)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo\n\nPrevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in\ncase pattern_len is equal to zero and the device FIFO is not empty.(CVE-2025-37969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmodule: ensure that kobject_put() is safe for module type kobjects\n\nIn \u0026apos;lookup_or_create_module_kobject()\u0026apos;, an internal kobject is created\nusing \u0026apos;module_ktype\u0026apos;. So call to \u0026apos;kobject_put()\u0026apos; on error handling\npath causes an attempt to use an uninitialized completion pointer in\n\u0026apos;module_kobject_release()\u0026apos;. In this scenario, we just want to release\nkobject without an extra synchronization required for a regular module\nunloading process, so adding an extra check whether \u0026apos;complete()\u0026apos; is\nactually required makes \u0026apos;kobject_put()\u0026apos; safe.(CVE-2025-37995)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: wait barrier before returning discard request with REQ_NOWAIT\n\nraid10_handle_discard should wait barrier before returning a discard bio\nwhich has REQ_NOWAIT. And there is no need to print warning calltrace\nif a discard bio has REQ_NOWAIT flag. Quality engineer usually checks\ndmesg and reports error if dmesg has warning/error calltrace.(CVE-2025-40325)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-96.0.0.89.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-96.0.0.89.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-96.0.0.89.oe2403.aarch64.rpm","kernel-6.6.0-96.0.0.89.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-96.0.0.89.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-96.0.0.89.oe2403.aarch64.rpm","kernel-devel-6.6.0-96.0.0.89.oe2403.aarch64.rpm","kernel-headers-6.6.0-96.0.0.89.oe2403.aarch64.rpm","kernel-source-6.6.0-96.0.0.89.oe2403.aarch64.rpm","kernel-tools-6.6.0-96.0.0.89.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-96.0.0.89.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-96.0.0.89.oe2403.aarch64.rpm","perf-6.6.0-96.0.0.89.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-96.0.0.89.oe2403.aarch64.rpm","python3-perf-6.6.0-96.0.0.89.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-96.0.0.89.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-96.0.0.89.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-96.0.0.89.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-96.0.0.89.oe2403.x86_64.rpm","kernel-6.6.0-96.0.0.89.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-96.0.0.89.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-96.0.0.89.oe2403.x86_64.rpm","kernel-devel-6.6.0-96.0.0.89.oe2403.x86_64.rpm","kernel-headers-6.6.0-96.0.0.89.oe2403.x86_64.rpm","kernel-source-6.6.0-96.0.0.89.oe2403.x86_64.rpm","kernel-tools-6.6.0-96.0.0.89.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-96.0.0.89.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-96.0.0.89.oe2403.x86_64.rpm","perf-6.6.0-96.0.0.89.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-96.0.0.89.oe2403.x86_64.rpm","python3-perf-6.6.0-96.0.0.89.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-96.0.0.89.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1629"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47716"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58100"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21872"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21925"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21966"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22126"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23131"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23148"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23156"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37857"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37916"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37921"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37923"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37926"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37958"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37969"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37995"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40325"}],"database_specific":{"severity":"High"}}