{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
          "kernel-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
          "kernel-debuginfo-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
          "kernel-debugsource-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
          "kernel-devel-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
          "kernel-extra-modules-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
          "kernel-headers-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
          "kernel-source-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
          "kernel-tools-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
          "kernel-tools-devel-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
          "perf-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
          "perf-debuginfo-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
          "python3-perf-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-144.0.0.140.oe2403sp2.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
          "kernel-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
          "kernel-debuginfo-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
          "kernel-debugsource-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
          "kernel-devel-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
          "kernel-extra-modules-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
          "kernel-headers-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
          "kernel-source-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
          "kernel-tools-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
          "kernel-tools-devel-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
          "perf-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
          "perf-debuginfo-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
          "python3-perf-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP2",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-144.0.0.140.oe2403sp2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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\niommu/s390: Implement blocking domain\n\nThis fixes a crash when surprise hot-unplugging a PCI device. This crash\nhappens because during hot-unplug __iommu_group_set_domain_nofail()\nattaching the default domain fails when the platform no longer\nrecognizes the device as it has already been removed and we end up with\na NULL domain pointer and UAF. This is exactly the case referred to in\nthe second comment in __iommu_device_set_domain() and just as stated\nthere if we can instead attach the blocking domain the UAF is prevented\nas this can handle the already removed device. Implement the blocking\ndomain to use this handling.  With this change, the crash is fixed but\nwe still hit a warning attempting to change DMA ownership on a blocked\ndevice.(CVE-2024-53232)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu: Fix two issues in iommu_copy_struct_from_user()\n\nIn the review for iommu_copy_struct_to_user() helper, Matt pointed out that\na NULL pointer should be rejected prior to dereferencing it:\nhttps://lore.kernel.org/all/(CVE-2025-37900)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Avoid race in open_cached_dir with lease breaks\n\nA pre-existing valid cfid returned from find_or_create_cached_dir might\nrace with a lease break, meaning open_cached_dir doesn\u0026apos;t consider it\nvalid, and thinks it\u0026apos;s newly-constructed. This leaks a dentry reference\nif the allocation occurs before the queued lease break work runs.\n\nAvoid the race by extending holding the cfid_list_lock across\nfind_or_create_cached_dir and when the result is checked.(CVE-2025-37954)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: prio: fix a race in prio_tune()\n\nGerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer\nfires at the wrong time.\n\nThe race is as follows:\n\nCPU 0                                 CPU 1\n[1]: lock root\n[2]: qdisc_tree_flush_backlog()\n[3]: unlock root\n |\n |                                    [5]: lock root\n |                                    [6]: rehash\n |                                    [7]: qdisc_tree_reduce_backlog()\n |\n[4]: qdisc_put()\n\nThis can be abused to underflow a parent\u0026apos;s qlen.\n\nCalling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()\nshould fix the race, because all packets will be purged from the qdisc\nbefore releasing the lock.(CVE-2025-38083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix potential deadlock in MR deregistration\n\nThe issue arises when kzalloc() is invoked while holding umem_mutex or\nany other lock acquired under umem_mutex. This is problematic because\nkzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke\nmmu_notifier_invalidate_range_start(). This function can lead to\nmlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again,\nresulting in a deadlock.\n\nThe problematic flow:\n             CPU0                      |              CPU1\n---------------------------------------|------------------------------------------------\nmlx5_ib_dereg_mr()                     |\n \u2192 revoke_mr()                         |\n   \u2192 mutex_lock(\u0026amp;umem_odp-\u0026gt;umem_mutex) |\n                                       | mlx5_mkey_cache_init()\n                                       |  \u2192 mutex_lock(\u0026amp;dev-\u0026gt;cache.rb_lock)\n                                       |  \u2192 mlx5r_cache_create_ent_locked()\n                                       |    \u2192 kzalloc(GFP_KERNEL)\n                                       |      \u2192 fs_reclaim()\n                                       |        \u2192 mmu_notifier_invalidate_range_start()\n                                       |          \u2192 mlx5_ib_invalidate_range()\n                                       |            \u2192 mutex_lock(\u0026amp;umem_odp-\u0026gt;umem_mutex)\n   \u2192 cache_ent_find_and_store()        |\n     \u2192 mutex_lock(\u0026amp;dev-\u0026gt;cache.rb_lock) |\n\nAdditionally, when kzalloc() is called from within\ncache_ent_find_and_store(), we encounter the same deadlock due to\nre-acquisition of umem_mutex.\n\nSolve by releasing umem_mutex in dereg_mr() after umr_revoke_mr()\nand before acquiring rb_lock. This ensures that we don\u0026apos;t hold\numem_mutex while performing memory allocations that could trigger\nthe reclaim path.\n\nThis change prevents the deadlock by ensuring proper lock ordering and\navoiding holding locks during memory allocation operations that could\ntrigger the reclaim path.\n\nThe following lockdep warning demonstrates the deadlock:\n\n python3/20557 is trying to acquire lock:\n ffff888387542128 (\u0026amp;umem_odp-\u0026gt;umem_mutex){+.+.}-{4:4}, at:\n mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib]\n\n but task is already holding lock:\n ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at:\n unmap_vmas+0x7b/0x1a0\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -\u0026gt; #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:\n       fs_reclaim_acquire+0x60/0xd0\n       mem_cgroup_css_alloc+0x6f/0x9b0\n       cgroup_init_subsys+0xa4/0x240\n       cgroup_init+0x1c8/0x510\n       start_kernel+0x747/0x760\n       x86_64_start_reservations+0x25/0x30\n       x86_64_start_kernel+0x73/0x80\n       common_startup_64+0x129/0x138\n\n -\u0026gt; #2 (fs_reclaim){+.+.}-{0:0}:\n       fs_reclaim_acquire+0x91/0xd0\n       __kmalloc_cache_noprof+0x4d/0x4c0\n       mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib]\n       mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib]\n       mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib]\n       __mlx5_ib_add+0x4b/0x190 [mlx5_ib]\n       mlx5r_probe+0xd9/0x320 [mlx5_ib]\n       auxiliary_bus_probe+0x42/0x70\n       really_probe+0xdb/0x360\n       __driver_probe_device+0x8f/0x130\n       driver_probe_device+0x1f/0xb0\n       __driver_attach+0xd4/0x1f0\n       bus_for_each_dev+0x79/0xd0\n       bus_add_driver+0xf0/0x200\n       driver_register+0x6e/0xc0\n       __auxiliary_driver_register+0x6a/0xc0\n       do_one_initcall+0x5e/0x390\n       do_init_module+0x88/0x240\n       init_module_from_file+0x85/0xc0\n       idempotent_init_module+0x104/0x300\n       __x64_sys_finit_module+0x68/0xc0\n       do_syscall_64+0x6d/0x140\n       entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n -\u0026gt; #1 (\u0026amp;dev-\u0026gt;cache.rb_lock){+.+.}-{4:4}:\n       __mutex_lock+0x98/0xf10\n       __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib]\n       mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib]\n       ib_dereg_mr_user+0x85/0x1f0 [ib_core]\n  \n---truncated---(CVE-2025-38373)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Harden s32ton() against conversion to 0 bits\n\nTesting by the syzbot fuzzer showed that the HID core gets a\nshift-out-of-bounds exception when it tries to convert a 32-bit\nquantity to a 0-bit quantity.  Ideally this should never occur, but\nthere are buggy devices and some might have a report field with size\nset to zero; we shouldn\u0026apos;t reject the report or the device just because\nof that.\n\nInstead, harden the s32ton() routine so that it returns a reasonable\nresult instead of crashing when it is called with the number of bits\nset to 0 -- the same as what snto32() does.(CVE-2025-38556)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Reject narrower access to pointer ctx fields\n\nThe following BPF program, simplified from a syzkaller repro, causes a\nkernel warning:\n\n    r0 = *(u8 *)(r1 + 169);\n    exit;\n\nWith pointer field sk being at offset 168 in __sk_buff. This access is\ndetected as a narrower read in bpf_skb_is_valid_access because it\ndoesn\u0026apos;t match offsetof(struct __sk_buff, sk). It is therefore allowed\nand later proceeds to bpf_convert_ctx_access. Note that for the\n\u0026quot;is_narrower_load\u0026quot; case in the convert_ctx_accesses(), the insn-\u0026gt;off\nis aligned, so the cnt may not be 0 because it matches the\noffsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,\nthe target_size stays 0 and the verifier errors with a kernel warning:\n\n    verifier bug: error during ctx access conversion(1)\n\nThis patch fixes that to return a proper \u0026quot;invalid bpf_context access\noff=X size=Y\u0026quot; error on the load instruction.\n\nThe same issue affects multiple other fields in context structures that\nallow narrow access. Some other non-affected fields (for sk_msg,\nsk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for\nconsistency.\n\nNote this syzkaller crash was reported in the \u0026quot;Closes\u0026quot; link below, which\nused to be about a different bug, fixed in\ncommit fce7bd8e385a (\u0026quot;bpf/verifier: Handle BPF_LOAD_ACQ instructions\nin insn_def_regno()\u0026quot;). Because syzbot somehow confused the two bugs,\nthe new crash and repro didn\u0026apos;t get reported to the mailing list.(CVE-2025-38591)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: No more self recovery\n\nWhen a node withdraws and it turns out that it is the only node that has\nthe filesystem mounted, gfs2 currently tries to replay the local journal\nto bring the filesystem back into a consistent state.  Not only is that\na very bad idea, it has also never worked because gfs2_recover_func()\nwill refuse to do anything during a withdraw.\n\nHowever, before even getting to this point, gfs2_recover_func()\ndereferences sdp-\u0026gt;sd_jdesc-\u0026gt;jd_inode.  This was a use-after-free before\ncommit 04133b607a78 (\u0026quot;gfs2: Prevent double iput for journal on error\u0026quot;)\nand is a NULL pointer dereference since then.\n\nSimply get rid of self recovery to fix that.(CVE-2025-38659)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/net: commit partial buffers on retry\n\nRing provided buffers are potentially only valid within the single\nexecution context in which they were acquired. io_uring deals with this\nand invalidates them on retry. But on the networking side, if\nMSG_WAITALL is set, or if the socket is of the streaming type and too\nlittle was processed, then it will hang on to the buffer rather than\nrecycle or commit it. This is problematic for two reasons:\n\n1) If someone unregisters the provided buffer ring before a later retry,\n   then the req-\u0026gt;buf_list will no longer be valid.\n\n2) If multiple sockers are using the same buffer group, then multiple\n   receives can consume the same memory. This can cause data corruption\n   in the application, as either receive could land in the same\n   userspace buffer.\n\nFix this by disallowing partial retries from pinning a provided buffer\nacross multiple executions, if ring provided buffers are used.(CVE-2025-38730)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()\n\nIn the interrupt handler rain_interrupt(), the buffer full check on\nrain-\u0026gt;buf_len is performed before acquiring rain-\u0026gt;buf_lock. This\ncreates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as\nrain-\u0026gt;buf_len is concurrently accessed and modified in the work\nhandler rain_irq_work_handler() under the same lock.\n\nMultiple interrupt invocations can race, with each reading buf_len\nbefore it becomes full and then proceeding. This can lead to both\ninterrupts attempting to write to the buffer, incrementing buf_len\nbeyond its capacity (DATA_SIZE) and causing a buffer overflow.\n\nFix this bug by moving the spin_lock() to before the buffer full\ncheck. This ensures that the check and the subsequent buffer modification\nare performed atomically, preventing the race condition. An corresponding\nspin_unlock() is added to the overflow path to correctly release the\nlock.\n\nThis possible bug was found by an experimental static analysis tool\ndeveloped by our team.(CVE-2025-39713)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd/pgtbl: Fix possible race while increase page table level\n\nThe AMD IOMMU host page table implementation supports dynamic page table levels\n(up to 6 levels), starting with a 3-level configuration that expands based on\nIOVA address. The kernel maintains a root pointer and current page table level\nto enable proper page table walks in alloc_pte()/fetch_pte() operations.\n\nThe IOMMU IOVA allocator initially starts with 32-bit address and onces its\nexhuasted it switches to 64-bit address (max address is determined based\non IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU\ndriver increases page table level.\n\nBut in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads\npgtable-\u0026gt;[root/mode] without lock. So its possible that in exteme corner case,\nwhen increase_address_space() is updating pgtable-\u0026gt;[root/mode], fetch_pte()\nreads wrong page table level (pgtable-\u0026gt;mode). It does compare the value with\nlevel encoded in page table and returns NULL. This will result is\niommu_unmap ops to fail and upper layer may retry/log WARN_ON.\n\nCPU 0                                         CPU 1\n------                                       ------\nmap pages                                    unmap pages\nalloc_pte() -\u0026gt; increase_address_space()      iommu_v1_unmap_pages() -\u0026gt; fetch_pte()\n  pgtable-\u0026gt;root = pte (new root value)\n                                             READ pgtable-\u0026gt;[mode/root]\n\t\t\t\t\t       Reads new root, old mode\n  Updates mode (pgtable-\u0026gt;mode += 1)\n\nSince Page table level updates are infrequent and already synchronized with a\nspinlock, implement seqcount to enable lock-free read operations on the read path.(CVE-2025-39961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: check the return value of pinmux_ops::get_function_name()\n\nWhile the API contract in docs doesn\u0026apos;t specify it explicitly, the\ngeneric implementation of the get_function_name() callback from struct\npinmux_ops - pinmux_generic_get_function_name() - can fail and return\nNULL. This is already checked in pinmux_check_ops() so add a similar\ncheck in pinmux_func_name_to_selector() instead of passing the returned\npointer right down to strcmp() where the NULL can get dereferenced. This\nis normal operation when adding new pinfunctions.(CVE-2025-40030)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies\n\nWhen adding dependencies with drm_sched_job_add_dependency(), that\nfunction consumes the fence reference both on success and failure, so in\nthe latter case the dma_fence_put() on the error path (xarray failed to\nexpand) is a double free.\n\nInterestingly this bug appears to have been present ever since\ncommit ebd5f74255b9 (\u0026quot;drm/sched: Add dependency tracking\u0026quot;), since the code\nback then looked like this:\n\ndrm_sched_job_add_implicit_dependencies():\n...\n       for (i = 0; i \u0026lt; fence_count; i++) {\n               ret = drm_sched_job_add_dependency(job, fences[i]);\n               if (ret)\n                       break;\n       }\n\n       for (; i \u0026lt; fence_count; i++)\n               dma_fence_put(fences[i]);\n\nWhich means for the failing \u0026apos;i\u0026apos; the dma_fence_put was already a double\nfree. Possibly there were no users at that time, or the test cases were\ninsufficient to hit it.\n\nThe bug was then only noticed and fixed after\ncommit 9c2ba265352a (\u0026quot;drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2\u0026quot;)\nlanded, with its fixup of\ncommit 4eaf02d6076c (\u0026quot;drm/scheduler: fix drm_sched_job_add_implicit_dependencies\u0026quot;).\n\nAt that point it was a slightly different flavour of a double free, which\ncommit 963d0b356935 (\u0026quot;drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder\u0026quot;)\nnoticed and attempted to fix.\n\nBut it only moved the double free from happening inside the\ndrm_sched_job_add_dependency(), when releasing the reference not yet\nobtained, to the caller, when releasing the reference already released by\nthe former in the failure case.\n\nAs such it is not easy to identify the right target for the fixes tag so\nlets keep it simple and just continue the chain.\n\nWhile fixing we also improve the comment and explain the reason for taking\nthe reference and not dropping it.(CVE-2025-40096)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: delete x-\u0026gt;tunnel as we delete x\n\nThe ipcomp fallback tunnels currently get deleted (from the various\nlists and hashtables) as the last user state that needed that fallback\nis destroyed (not deleted). If a reference to that user state still\nexists, the fallback state will remain on the hashtables/lists,\ntriggering the WARN in xfrm_state_fini. Because of those remaining\nreferences, the fix in commit f75a2804da39 (\u0026quot;xfrm: destroy xfrm_state\nsynchronously on net exit path\u0026quot;) is not complete.\n\nWe recently fixed one such situation in TCP due to defered freeing of\nskbs (commit 9b6412e6979f (\u0026quot;tcp: drop secpath at the same time as we\ncurrently drop dst\u0026quot;)). This can also happen due to IP reassembly: skbs\nwith a secpath remain on the reassembly queue until netns\ndestruction. If we can\u0026apos;t guarantee that the queues are flushed by the\ntime xfrm_state_fini runs, there may still be references to a (user)\nxfrm_state, preventing the timely deletion of the corresponding\nfallback state.\n\nInstead of chasing each instance of skbs holding a secpath one by one,\nthis patch fixes the issue directly within xfrm, by deleting the\nfallback state as soon as the last user state depending on it has been\ndeleted. Destruction will still happen when the final reference is\ndropped.\n\nA separate lockdep class for the fallback state is required since\nwe\u0026apos;re going to lock x-\u0026gt;tunnel while x is locked.(CVE-2025-40215)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix livelock in synchronous file put from fuseblk workers\n\nI observed a hang when running generic/323 against a fuseblk server.\nThis test opens a file, initiates a lot of AIO writes to that file\ndescriptor, and closes the file descriptor before the writes complete.\nUnsurprisingly, the AIO exerciser threads are mostly stuck waiting for\nresponses from the fuseblk server:\n\n# cat /proc/372265/task/372313/stack\n[\u0026lt;0\u0026gt;] request_wait_answer+0x1fe/0x2a0 [fuse]\n[\u0026lt;0\u0026gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_do_getattr+0xfc/0x1f0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_file_read_iter+0xbe/0x1c0 [fuse]\n[\u0026lt;0\u0026gt;] aio_read+0x130/0x1e0\n[\u0026lt;0\u0026gt;] io_submit_one+0x542/0x860\n[\u0026lt;0\u0026gt;] __x64_sys_io_submit+0x98/0x1a0\n[\u0026lt;0\u0026gt;] do_syscall_64+0x37/0xf0\n[\u0026lt;0\u0026gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nBut the /weird/ part is that the fuseblk server threads are waiting for\nresponses from itself:\n\n# cat /proc/372210/task/372232/stack\n[\u0026lt;0\u0026gt;] request_wait_answer+0x1fe/0x2a0 [fuse]\n[\u0026lt;0\u0026gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_file_put+0x9a/0xd0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_release+0x36/0x50 [fuse]\n[\u0026lt;0\u0026gt;] __fput+0xec/0x2b0\n[\u0026lt;0\u0026gt;] task_work_run+0x55/0x90\n[\u0026lt;0\u0026gt;] syscall_exit_to_user_mode+0xe9/0x100\n[\u0026lt;0\u0026gt;] do_syscall_64+0x43/0xf0\n[\u0026lt;0\u0026gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nThe fuseblk server is fuse2fs so there\u0026apos;s nothing all that exciting in\nthe server itself.  So why is the fuse server calling fuse_file_put?\nThe commit message for the fstest sheds some light on that:\n\n\u0026quot;By closing the file descriptor before calling io_destroy, you pretty\nmuch guarantee that the last put on the ioctx will be done in interrupt\ncontext (during I/O completion).\n\nAha.  AIO fgets a new struct file from the fd when it queues the ioctx.\nThe completion of the FUSE_WRITE command from userspace causes the fuse\nserver to call the AIO completion function.  The completion puts the\nstruct file, queuing a delayed fput to the fuse server task.  When the\nfuse server task returns to userspace, it has to run the delayed fput,\nwhich in the case of a fuseblk server, it does synchronously.\n\nSending the FUSE_RELEASE command sychronously from fuse server threads\nis a bad idea because a client program can initiate enough simultaneous\nAIOs such that all the fuse server threads end up in delayed_fput, and\nnow there aren\u0026apos;t any threads left to handle the queued fuse commands.\n\nFix this by only using asynchronous fputs when closing files, and leave\na comment explaining why.(CVE-2025-40220)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/notify: call exportfs_encode_fid with s_umount\n\nCalling intotify_show_fdinfo() on fd watching an overlayfs inode, while\nthe overlayfs is being unmounted, can lead to dereferencing NULL ptr.\n\nThis issue was found by syzkaller.\n\nRace Condition Diagram:\n\nThread 1                           Thread 2\n--------                           --------\n\ngeneric_shutdown_super()\n shrink_dcache_for_umount\n  sb-\u0026gt;s_root = NULL\n\n                    |\n                    |             vfs_read()\n                    |              inotify_fdinfo()\n                    |               * inode get from mark *\n                    |               show_mark_fhandle(m, inode)\n                    |                exportfs_encode_fid(inode, ..)\n                    |                 ovl_encode_fh(inode, ..)\n                    |                  ovl_check_encode_origin(inode)\n                    |                   * deref i_sb-\u0026gt;s_root *\n                    |\n                    |\n                    v\n fsnotify_sb_delete(sb)\n\nWhich then leads to:\n\n[   32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[   32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\n[   32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none)\n\n\u0026lt;snip registers, unreliable trace\u0026gt;\n\n[   32.143353] Call Trace:\n[   32.143732]  ovl_encode_fh+0xd5/0x170\n[   32.144031]  exportfs_encode_inode_fh+0x12f/0x300\n[   32.144425]  show_mark_fhandle+0xbe/0x1f0\n[   32.145805]  inotify_fdinfo+0x226/0x2d0\n[   32.146442]  inotify_show_fdinfo+0x1c5/0x350\n[   32.147168]  seq_show+0x530/0x6f0\n[   32.147449]  seq_read_iter+0x503/0x12a0\n[   32.148419]  seq_read+0x31f/0x410\n[   32.150714]  vfs_read+0x1f0/0x9e0\n[   32.152297]  ksys_read+0x125/0x240\n\nIOW ovl_check_encode_origin derefs inode-\u0026gt;i_sb-\u0026gt;s_root, after it was set\nto NULL in the unmount path.\n\nFix it by protecting calling exportfs_encode_fid() from\nshow_mark_fhandle() with s_umount lock.\n\nThis form of fix was suggested by Amir in [1].\n\n[1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/(CVE-2025-40237)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix unlikely race in gdlm_put_lock\n\nIn gdlm_put_lock(), there is a small window of time in which the\nDFL_UNMOUNT flag has been set but the lockspace hasn\u0026apos;t been released,\nyet.  In that window, dlm may still call gdlm_ast() and gdlm_bast().\nTo prevent it from dereferencing freed glock objects, only free the\nglock if the lockspace has actually been released.(CVE-2025-40242)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndevlink: rate: Unset parent pointer in devl_rate_nodes_destroy\n\nThe function devl_rate_nodes_destroy is documented to \u0026quot;Unset parent for\nall rate objects\u0026quot;. However, it was only calling the driver-specific\n`rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing\nthe parent\u0026apos;s refcount, without actually setting the\n`devlink_rate-\u0026gt;parent` pointer to NULL.\n\nThis leaves a dangling pointer in the `devlink_rate` struct, which cause\nrefcount error in netdevsim[1] and mlx5[2]. In addition, this is\ninconsistent with the behavior of `devlink_nl_rate_parent_node_set`,\nwhere the parent pointer is correctly cleared.\n\nThis patch fixes the issue by explicitly setting `devlink_rate-\u0026gt;parent`\nto NULL after notifying the driver, thus fulfilling the function\u0026apos;s\ndocumented behavior for all rate objects.\n\n[1]\nrepro steps:\necho 1 \u0026gt; /sys/bus/netdevsim/new_device\ndevlink dev eswitch set netdevsim/netdevsim1 mode switchdev\necho 1 \u0026gt; /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs\ndevlink port function rate add netdevsim/netdevsim1/test_node\ndevlink port function rate set netdevsim/netdevsim1/128 parent test_node\necho 1 \u0026gt; /sys/bus/netdevsim/del_device\n\ndmesg:\nrefcount_t: decrement hit 0; leaking memory.\nWARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0\nCPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x42/0xe0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n devl_rate_leaf_destroy+0x8d/0x90\n __nsim_dev_port_del+0x6c/0x70 [netdevsim]\n nsim_dev_reload_destroy+0x11c/0x140 [netdevsim]\n nsim_drv_remove+0x2b/0xb0 [netdevsim]\n device_release_driver_internal+0x194/0x1f0\n bus_remove_device+0xc6/0x130\n device_del+0x159/0x3c0\n device_unregister+0x1a/0x60\n del_device_store+0x111/0x170 [netdevsim]\n kernfs_fop_write_iter+0x12e/0x1e0\n vfs_write+0x215/0x3d0\n ksys_write+0x5f/0xd0\n do_syscall_64+0x55/0x10f0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\ndevlink dev eswitch set pci/0000:08:00.0 mode switchdev\ndevlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000\ndevlink port function rate add pci/0000:08:00.0/group1\ndevlink port function rate set pci/0000:08:00.0/32768 parent group1\nmodprobe -r mlx5_ib mlx5_fwctl mlx5_core\n\ndmesg:\nrefcount_t: decrement hit 0; leaking memory.\nWARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0\nCPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x42/0xe0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n devl_rate_leaf_destroy+0x8d/0x90\n mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core]\n mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core]\n mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core]\n mlx5_sf_esw_event+0xc4/0x120 [mlx5_core]\n notifier_call_chain+0x33/0xa0\n blocking_notifier_call_chain+0x3b/0x50\n mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core]\n mlx5_eswitch_disable+0x63/0x90 [mlx5_core]\n mlx5_unload+0x1d/0x170 [mlx5_core]\n mlx5_uninit_one+0xa2/0x130 [mlx5_core]\n remove_one+0x78/0xd0 [mlx5_core]\n pci_device_remove+0x39/0xa0\n device_release_driver_internal+0x194/0x1f0\n unbind_store+0x99/0xa0\n kernfs_fop_write_iter+0x12e/0x1e0\n vfs_write+0x215/0x3d0\n ksys_write+0x5f/0xd0\n do_syscall_64+0x53/0x1f0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-40251)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: fix uaf in proc_readdir_de()\n\nPde is erased from subdir rbtree through rb_erase(), but not set the node\nto EMPTY, which may result in uaf access.  We should use RB_CLEAR_NODE()\nset the erased node to EMPTY, then pde_subdir_next() will return NULL to\navoid uaf access.\n\nWe found an uaf issue while using stress-ng testing, need to run testcase\ngetdent and tun in the same time.  The steps of the issue is as follows:\n\n1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current\n   pde is tun3;\n\n2) in the [time windows] unregister netdevice tun3 and tun2, and erase\n   them from rbtree.  erase tun3 first, and then erase tun2.  the\n   pde(tun2) will be released to slab;\n\n3) continue to getdent process, then pde_subdir_next() will return\n   pde(tun2) which is released, it will case uaf access.\n\nCPU 0                                      |    CPU 1\n-------------------------------------------------------------------------\ntraverse dir /proc/pid/net/dev_snmp6/      |   unregister_netdevice(tun-\u0026gt;dev)   //tun3 tun2\nsys_getdents64()                           |\n  iterate_dir()                            |\n    proc_readdir()                         |\n      proc_readdir_de()                    |     snmp6_unregister_dev()\n        pde_get(de);                       |       proc_remove()\n        read_unlock(\u0026amp;proc_subdir_lock);    |         remove_proc_subtree()\n                                           |           write_lock(\u0026amp;proc_subdir_lock);\n        [time window]                      |           rb_erase(\u0026amp;root-\u0026gt;subdir_node, \u0026amp;parent-\u0026gt;subdir);\n                                           |           write_unlock(\u0026amp;proc_subdir_lock);\n        read_lock(\u0026amp;proc_subdir_lock);      |\n        next = pde_subdir_next(de);        |\n        pde_put(de);                       |\n        de = next;    //UAF                |\n\nrbtree of dev_snmp6\n                        |\n                    pde(tun3)\n                     /    \\\n                  NULL  pde(tun2)(CVE-2025-40271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/secretmem: fix use-after-free race in fault handler\n\nWhen a page fault occurs in a secret memory file created with\n`memfd_secret(2)`, the kernel will allocate a new folio for it, mark the\nunderlying page as not-present in the direct map, and add it to the file\nmapping.\n\nIf two tasks cause a fault in the same page concurrently, both could end\nup allocating a folio and removing the page from the direct map, but only\none would succeed in adding the folio to the file mapping.  The task that\nfailed undoes the effects of its attempt by (a) freeing the folio again\nand (b) putting the page back into the direct map.  However, by doing\nthese two operations in this order, the page becomes available to the\nallocator again before it is placed back in the direct mapping.\n\nIf another task attempts to allocate the page between (a) and (b), and the\nkernel tries to access it via the direct map, it would result in a\nsupervisor not-present page fault.\n\nFix the ordering to restore the direct map before the folio is freed.(CVE-2025-40272)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE\n\nThis data originates from userspace and is used in buffer offset\ncalculations which could potentially overflow causing an out-of-bounds\naccess.(CVE-2025-40277)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()\n\nIn the parse_adv_monitor_pattern() function, the value of\nthe \u0026apos;length\u0026apos; variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251).\nThe size of the \u0026apos;value\u0026apos; array in the mgmt_adv_pattern structure is 31.\nIf the value of \u0026apos;pattern[i].length\u0026apos; is set in the user space\nand exceeds 31, the \u0026apos;patterns[i].value\u0026apos; array can be accessed\nout of bound when copied.\n\nIncreasing the size of the \u0026apos;value\u0026apos; array in\nthe \u0026apos;mgmt_adv_pattern\u0026apos; structure will break the userspace.\nConsidering this, and to avoid OOB access revert the limits for \u0026apos;offset\u0026apos;\nand \u0026apos;length\u0026apos; back to the value of HCI_MAX_AD_LENGTH.\n\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with SVACE.(CVE-2025-40294)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: validate skb length for unknown CC opcode\n\nIn hci_cmd_complete_evt(), if the command complete event has an unknown\nopcode, we assume the first byte of the remaining skb-\u0026gt;data contains the\nreturn status. However, parameter data has previously been pulled in\nhci_event_func(), which may leave the skb empty. If so, using skb-\u0026gt;data[0]\nfor the return status uses un-init memory.\n\nThe fix is to check skb-\u0026gt;len before using skb-\u0026gt;data.(CVE-2025-40301)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: bcsp: receive data only if registered\n\nCurrently, bcsp_recv() can be called even when the BCSP protocol has not\nbeen registered. This leads to a NULL pointer dereference, as shown in\nthe following stack trace:\n\n    KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]\n    RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590\n    Call Trace:\n     \u0026lt;TASK\u0026gt;\n     hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627\n     tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290\n     tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706\n     vfs_ioctl fs/ioctl.c:51 [inline]\n     __do_sys_ioctl fs/ioctl.c:907 [inline]\n     __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893\n     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nTo prevent this, ensure that the HCI_UART_REGISTERED flag is set before\nprocessing received data. If the protocol is not registered, return\n-EUNATCH.(CVE-2025-40308)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once\n\nhci_cmd_sync_dequeue_once() does lookup and then cancel\nthe entry under two separate lock sections. Meanwhile,\nhci_cmd_sync_work() can also delete the same entry,\nleading to double list_del() and \u0026quot;UAF\u0026quot;.\n\nFix this by holding cmd_sync_work_lock across both\nlookup and cancel, so that the entry cannot be removed\nconcurrently.(CVE-2025-40318)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfutex: Don\u0026apos;t leak robust_list pointer on exec race\n\nsys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()\nto check if the calling task is allowed to access another task\u0026apos;s\nrobust_list pointer. This check is racy against a concurrent exec() in the\ntarget process.\n\nDuring exec(), a task may transition from a non-privileged binary to a\nprivileged one (e.g., setuid binary) and its credentials/memory mappings\nmay change. If get_robust_list() performs ptrace_may_access() before\nthis transition, it may erroneously allow access to sensitive information\nafter the target becomes privileged.\n\nA racy access allows an attacker to exploit a window during which\nptrace_may_access() passes before a target process transitions to a\nprivileged state via exec().\n\nFor example, consider a non-privileged task T that is about to execute a\nsetuid-root binary. An attacker task A calls get_robust_list(T) while T\nis still unprivileged. Since ptrace_may_access() checks permissions\nbased on current credentials, it succeeds. However, if T begins exec\nimmediately afterwards, it becomes privileged and may change its memory\nmappings. Because get_robust_list() proceeds to access T-\u0026gt;robust_list\nwithout synchronizing with exec() it may read user-space pointers from a\nnow-privileged process.\n\nThis violates the intended post-exec access restrictions and could\nexpose sensitive memory addresses or be used as a primitive in a larger\nexploit chain. Consequently, the race can lead to unauthorized\ndisclosure of information across privilege boundaries and poses a\npotential security risk.\n\nTake a read lock on signal-\u0026gt;exec_update_lock prior to invoking\nptrace_may_access() and accessing the robust_list/compat_robust_list.\nThis ensures that the target task\u0026apos;s exec state remains stable during the\ncheck, allowing for consistent and synchronized validation of\ncredentials.(CVE-2025-40341)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-fc: use lock accessing port_state and rport state\n\nnvme_fc_unregister_remote removes the remote port on a lport object at\nany point in time when there is no active association. This races with\nwith the reconnect logic, because nvme_fc_create_association is not\ntaking a lock to check the port_state and atomically increase the\nactive count on the rport.(CVE-2025-40342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-fc: avoid scheduling association deletion twice\n\nWhen forcefully shutting down a port via the configfs interface,\nnvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and\nthen nvmet_disable_port(). Both functions will eventually schedule all\nremaining associations for deletion.\n\nThe current implementation checks whether an association is about to be\nremoved, but only after the work item has already been scheduled. As a\nresult, it is possible for the first scheduled work item to free all\nresources, and then for the same work item to be scheduled again for\ndeletion.\n\nBecause the association list is an RCU list, it is not possible to take\na lock and remove the list entry directly, so it cannot be looked up\nagain. Instead, a flag (terminating) must be used to determine whether\nthe association is already in the process of being deleted.(CVE-2025-40343)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narch_topology: Fix incorrect error check in topology_parse_cpu_capacity()\n\nFix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()\nwhich causes the code to proceed with NULL clock pointers. The current\nlogic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both\nvalid pointers and NULL, leading to potential NULL pointer dereference\nin clk_get_rate().\n\nPer include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:\n\u0026quot;The error code within @ptr if it is an error pointer; 0 otherwise.\u0026quot;\n\nThis means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL\npointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)\nwhen cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be\ncalled when of_clk_get() returns NULL.\n\nReplace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid\npointers, preventing potential NULL pointer dereference in clk_get_rate().(CVE-2025-40346)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()\n\nThe syzbot reported issue in hfsplus_delete_cat():\n\n[   70.682285][ T9333] =====================================================\n[   70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220\n[   70.683640][ T9333]  hfsplus_subfolders_dec+0x1d7/0x220\n[   70.684141][ T9333]  hfsplus_delete_cat+0x105d/0x12b0\n[   70.684621][ T9333]  hfsplus_rmdir+0x13d/0x310\n[   70.685048][ T9333]  vfs_rmdir+0x5ba/0x810\n[   70.685447][ T9333]  do_rmdir+0x964/0xea0\n[   70.685833][ T9333]  __x64_sys_rmdir+0x71/0xb0\n[   70.686260][ T9333]  x64_sys_call+0xcd8/0x3cf0\n[   70.686695][ T9333]  do_syscall_64+0xd9/0x1d0\n[   70.687119][ T9333]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[   70.687646][ T9333]\n[   70.687856][ T9333] Uninit was stored to memory at:\n[   70.688311][ T9333]  hfsplus_subfolders_inc+0x1c2/0x1d0\n[   70.688779][ T9333]  hfsplus_create_cat+0x148e/0x1800\n[   70.689231][ T9333]  hfsplus_mknod+0x27f/0x600\n[   70.689730][ T9333]  hfsplus_mkdir+0x5a/0x70\n[   70.690146][ T9333]  vfs_mkdir+0x483/0x7a0\n[   70.690545][ T9333]  do_mkdirat+0x3f2/0xd30\n[   70.690944][ T9333]  __x64_sys_mkdir+0x9a/0xf0\n[   70.691380][ T9333]  x64_sys_call+0x2f89/0x3cf0\n[   70.691816][ T9333]  do_syscall_64+0xd9/0x1d0\n[   70.692229][ T9333]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[   70.692773][ T9333]\n[   70.692990][ T9333] Uninit was stored to memory at:\n[   70.693469][ T9333]  hfsplus_subfolders_inc+0x1c2/0x1d0\n[   70.693960][ T9333]  hfsplus_create_cat+0x148e/0x1800\n[   70.694438][ T9333]  hfsplus_fill_super+0x21c1/0x2700\n[   70.694911][ T9333]  mount_bdev+0x37b/0x530\n[   70.695320][ T9333]  hfsplus_mount+0x4d/0x60\n[   70.695729][ T9333]  legacy_get_tree+0x113/0x2c0\n[   70.696167][ T9333]  vfs_get_tree+0xb3/0x5c0\n[   70.696588][ T9333]  do_new_mount+0x73e/0x1630\n[   70.697013][ T9333]  path_mount+0x6e3/0x1eb0\n[   70.697425][ T9333]  __se_sys_mount+0x733/0x830\n[   70.697857][ T9333]  __x64_sys_mount+0xe4/0x150\n[   70.698269][ T9333]  x64_sys_call+0x2691/0x3cf0\n[   70.698704][ T9333]  do_syscall_64+0xd9/0x1d0\n[   70.699117][ T9333]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[   70.699730][ T9333]\n[   70.699946][ T9333] Uninit was created at:\n[   70.700378][ T9333]  __alloc_pages_noprof+0x714/0xe60\n[   70.700843][ T9333]  alloc_pages_mpol_noprof+0x2a2/0x9b0\n[   70.701331][ T9333]  alloc_pages_noprof+0xf8/0x1f0\n[   70.701774][ T9333]  allocate_slab+0x30e/0x1390\n[   70.702194][ T9333]  ___slab_alloc+0x1049/0x33a0\n[   70.702635][ T9333]  kmem_cache_alloc_lru_noprof+0x5ce/0xb20\n[   70.703153][ T9333]  hfsplus_alloc_inode+0x5a/0xd0\n[   70.703598][ T9333]  alloc_inode+0x82/0x490\n[   70.703984][ T9333]  iget_locked+0x22e/0x1320\n[   70.704428][ T9333]  hfsplus_iget+0x5c/0xba0\n[   70.704827][ T9333]  hfsplus_btree_open+0x135/0x1dd0\n[   70.705291][ T9333]  hfsplus_fill_super+0x1132/0x2700\n[   70.705776][ T9333]  mount_bdev+0x37b/0x530\n[   70.706171][ T9333]  hfsplus_mount+0x4d/0x60\n[   70.706579][ T9333]  legacy_get_tree+0x113/0x2c0\n[   70.707019][ T9333]  vfs_get_tree+0xb3/0x5c0\n[   70.707444][ T9333]  do_new_mount+0x73e/0x1630\n[   70.707865][ T9333]  path_mount+0x6e3/0x1eb0\n[   70.708270][ T9333]  __se_sys_mount+0x733/0x830\n[   70.708711][ T9333]  __x64_sys_mount+0xe4/0x150\n[   70.709158][ T9333]  x64_sys_call+0x2691/0x3cf0\n[   70.709630][ T9333]  do_syscall_64+0xd9/0x1d0\n[   70.710053][ T9333]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[   70.710611][ T9333]\n[   70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17\n[   70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[   70.712490][ T9333] =====================================================\n[   70.713085][ T9333] Disabling lock debugging due to kernel taint\n[   70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ...\n[   70.714159][ T9333] \n---truncated---(CVE-2025-40351)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: stacktrace: Disable KASAN checks for non-current tasks\n\nUnwinding the stack of a task other than current, KASAN would report\n\u0026quot;BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460\u0026quot;\n\nThere is a same issue on x86 and has been resolved by the commit\n84936118bdf3 (\u0026quot;x86/unwind: Disable KASAN checks for non-current tasks\u0026quot;)\nThe solution could be applied to RISC-V too.\n\nThis patch also can solve the issue:\nhttps://seclists.org/oss-sec/2025/q4/23\n\n[(CVE-2025-40358)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel: Fix KASAN global-out-of-bounds warning\n\nWhen running \u0026quot;perf mem record\u0026quot; command on CWF, the below KASAN\nglobal-out-of-bounds warning is seen.\n\n  ==================================================================\n  BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0\n  Read of size 4 at addr ffffffffb721d000 by task dtlb/9850\n\n  Call Trace:\n\n   kasan_report+0xb8/0xf0\n   cmt_latency_data+0x176/0x1b0\n   setup_arch_pebs_sample_data+0xf49/0x2560\n   intel_pmu_drain_arch_pebs+0x577/0xb00\n   handle_pmi_common+0x6c4/0xc80\n\nThe issue is caused by below code in __grt_latency_data(). The code\ntries to access x86_hybrid_pmu structure which doesn\u0026apos;t exist on\nnon-hybrid platform like CWF.\n\n        WARN_ON_ONCE(hybrid_pmu(event-\u0026gt;pmu)-\u0026gt;pmu_type == hybrid_big)\n\nSo add is_hybrid() check before calling this WARN_ON_ONCE to fix the\nglobal-out-of-bounds access issue.(CVE-2025-40359)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-40361)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Ensure XFD state on signal delivery\n\nSean reported [1] the following splat when running KVM tests:\n\n   WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70\n   Call Trace:\n    \u0026lt;TASK\u0026gt;\n    fpu__clear_user_states+0x9c/0x100\n    arch_do_signal_or_restart+0x142/0x210\n    exit_to_user_mode_loop+0x55/0x100\n    do_syscall_64+0x205/0x2c0\n    entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nChao further identified [2] a reproducible scenario involving signal\ndelivery: a non-AMX task is preempted by an AMX-enabled task which\nmodifies the XFD MSR.\n\nWhen the non-AMX task resumes and reloads XSTATE with init values,\na warning is triggered due to a mismatch between fpstate::xfd and the\nCPU\u0026apos;s current XFD state. fpu__clear_user_states() does not currently\nre-synchronize the XFD state after such preemption.\n\nInvoke xfd_update_state() which detects and corrects the mismatch if\nthere is a dynamic feature.\n\nThis also benefits the sigreturn path, as fpu__restore_sig() may call\nfpu__clear_user_states() when the sigframe is inaccessible.\n\n[ dhansen: minor changelog munging ](CVE-2025-68171)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Fix softlockup in ftrace_module_enable\n\nA soft lockup was observed when loading amdgpu module.\nIf a module has a lot of tracable functions, multiple calls\nto kallsyms_lookup can spend too much time in RCU critical\nsection and with disabled preemption, causing kernel panic.\nThis is the same issue that was fixed in\ncommit d0b24b4e91fc (\u0026quot;ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY\nkernels\u0026quot;) and commit 42ea22e754ba (\u0026quot;ftrace: Add cond_resched() to\nftrace_graph_set_hash()\u0026quot;).\n\nFix it the same way by adding cond_resched() in ftrace_module_enable.(CVE-2025-68173)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\namd/amdkfd: enhance kfd process check in switch partition\n\ncurrent switch partition only check if kfd_processes_table is empty.\nkfd_prcesses_table entry is deleted in kfd_process_notifier_release, but\nkfd_process tear down is in kfd_process_wq_release.\n\nconsider two processes:\n\nProcess A (workqueue) -\u0026gt; kfd_process_wq_release -\u0026gt; Access kfd_node member\nProcess B switch partition -\u0026gt; amdgpu_xcp_pre_partition_switch -\u0026gt; amdgpu_amdkfd_device_fini_sw\n-\u0026gt; kfd_node tear down.\n\nProcess A and B may trigger a race as shown in dmesg log.\n\nThis patch is to resolve the race by adding an atomic kfd_process counter\nkfd_processes_count, it increment as create kfd process, decrement as\nfinish kfd_process_wq_release.\n\nv2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pdds\nand bug fix. (Philip Yang)\n\n[3966658.307702] divide error: 0000 [#1] SMP NOPTI\n[3966658.350818]  i10nm_edac\n[3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted\n[3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu]\n[3966658.362839]  nfit\n[3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu]\n[3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 \u0026lt;f7\u0026gt; be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00\n[3966658.380967]  x86_pkg_temp_thermal\n[3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246\n[3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000\n[3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00\n[3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4\n[3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000\n[3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800\n[3966658.391533] FS:  0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000\n[3966658.391534] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0\n[3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\n[3966658.391536] PKRU: 55555554\n[3966658.391536] Call Trace:\n[3966658.391674]  deallocate_sdma_queue+0x38/0xa0 [amdgpu]\n[3966658.391762]  process_termination_cpsch+0x1ed/0x480 [amdgpu]\n[3966658.399754]  intel_powerclamp\n[3966658.402831]  kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu]\n[3966658.402908]  kfd_process_wq_release+0x1a/0x1a0 [amdgpu]\n[3966658.410516]  coretemp\n[3966658.434016]  process_one_work+0x1ad/0x380\n[3966658.434021]  worker_thread+0x49/0x310\n[3966658.438963]  kvm_intel\n[3966658.446041]  ? process_one_work+0x380/0x380\n[3966658.446045]  kthread+0x118/0x140\n[3966658.446047]  ? __kthread_bind_mask+0x60/0x60\n[3966658.446050]  ret_from_fork+0x1f/0x30\n[3966658.446053] Modules linked in: kpatch_20765354(OEK)\n[3966658.455310]  kvm\n[3966658.464534]  mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK)\n[3966658.473462]  idxd_mdev\n[3966658.482306]  kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo\n---truncated---(CVE-2025-68174)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: cadence: Check for the existence of cdns_pcie::ops before using it\n\ncdns_pcie::ops might not be populated by all the Cadence glue drivers. This\nis going to be true for the upcoming Sophgo platform which doesn\u0026apos;t set the\nops.\n\nHence, add a check to prevent NULL pointer dereference.\n\n[mani: reworded subject and description](CVE-2025-68176)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()\n\nUse RCU to avoid a pair of atomic operations and a potential\nUAF on dst_dev()-\u0026gt;flags.(CVE-2025-68188)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Add bpf_prog_run_data_pointers()\n\nsyzbot found that cls_bpf_classify() is able to change\ntc_skb_cb(skb)-\u0026gt;drop_reason triggering a warning in sk_skb_reason_drop().\n\nWARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline]\nWARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214\n\nstruct tc_skb_cb has been added in commit ec624fe740b4 (\u0026quot;net/sched:\nExtend qdisc control block with tc control block\u0026quot;), which added a wrong\ninteraction with db58ba459202 (\u0026quot;bpf: wire in data and data_end for\ncls_act_bpf\u0026quot;).\n\ndrop_reason was added later.\n\nAdd bpf_prog_run_data_pointers() helper to save/restore the net_sched\nstorage colliding with BPF data_meta/data_end.(CVE-2025-68200)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: add seqadj extension for natted connections\n\nSequence adjustment may be required for FTP traffic with PASV/EPSV modes.\ndue to need to re-write packet payload (IP, port) on the ftp control\nconnection. This can require changes to the TCP length and expected\nseq / ack_seq.\n\nThe easiest way to reproduce this issue is with PASV mode.\nExample ruleset:\ntable inet ftp_nat {\n        ct helper ftp_helper {\n                type \u0026quot;ftp\u0026quot; protocol tcp\n                l3proto inet\n        }\n\n        chain prerouting {\n                type filter hook prerouting priority 0; policy accept;\n                tcp dport 21 ct state new ct helper set \u0026quot;ftp_helper\u0026quot;\n        }\n}\ntable ip nat {\n        chain prerouting {\n                type nat hook prerouting priority -100; policy accept;\n                tcp dport 21 dnat ip prefix to ip daddr map {\n\t\t\t192.168.100.1 : 192.168.13.2/32 }\n        }\n\n        chain postrouting {\n                type nat hook postrouting priority 100 ; policy accept;\n                tcp sport 21 snat ip prefix to ip saddr map {\n\t\t\t192.168.13.2 : 192.168.100.1/32 }\n        }\n}\n\nNote that the ftp helper gets assigned *after* the dnat setup.\n\nThe inverse (nat after helper assign) is handled by an existing\ncheck in nf_nat_setup_info() and will not show the problem.\n\nTopoloy:\n\n +-------------------+     +----------------------------------+\n | FTP: 192.168.13.2 | \u0026lt;-\u0026gt; | NAT: 192.168.13.3, 192.168.100.1 |\n +-------------------+     +----------------------------------+\n                                      |\n                         +-----------------------+\n                         | Client: 192.168.100.2 |\n                         +-----------------------+\n\nftp nat changes do not work as expected in this case:\nConnected to 192.168.100.1.\n[..]\nftp\u0026gt; epsv\nEPSV/EPRT on IPv4 off.\nftp\u0026gt; ls\n227 Entering passive mode (192,168,100,1,209,129).\n421 Service not available, remote server has closed connection.\n\nKernel logs:\nMissing nfct_seqadj_ext_add() setup call\nWARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41\n[..]\n __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat]\n nf_nat_ftp+0x142/0x280 [nf_nat_ftp]\n help+0x4d1/0x880 [nf_conntrack_ftp]\n nf_confirm+0x122/0x2e0 [nf_conntrack]\n nf_hook_slow+0x3c/0xb0\n ..\n\nFix this by adding the required extension when a conntrack helper is assigned\nto a connection that has a nat binding.(CVE-2025-68206)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: account for current allocated stack depth in widen_imprecise_scalars()\n\nThe usage pattern for widen_imprecise_scalars() looks as follows:\n\n    prev_st = find_prev_entry(env, ...);\n    queued_st = push_stack(...);\n    widen_imprecise_scalars(env, prev_st, queued_st);\n\nWhere prev_st is an ancestor of the queued_st in the explored states\ntree. This ancestor is not guaranteed to have same allocated stack\ndepth as queued_st. E.g. in the following case:\n\n    def main():\n      for i in 1..2:\n        foo(i)        // same callsite, differnt param\n\n    def foo(i):\n      if i == 1:\n        use 128 bytes of stack\n      iterator based loop\n\nHere, for a second \u0026apos;foo\u0026apos; call prev_st-\u0026gt;allocated_stack is 128,\nwhile queued_st-\u0026gt;allocated_stack is much smaller.\nwiden_imprecise_scalars() needs to take this into account and avoid\naccessing bpf_verifier_state-\u0026gt;frame[*]-\u0026gt;stack out of bounds.(CVE-2025-68208)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot\n\nnvkm_falcon_fw::boot is allocated, but no one frees it. This causes a\nkmemleak warning.\n\nMake sure this data is deallocated.(CVE-2025-68235)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Don\u0026apos;t skip unrelated instruction if INT3/INTO is replaced\n\nWhen re-injecting a soft interrupt from an INT3, INT0, or (select) INTn\ninstruction, discard the exception and retry the instruction if the code\nstream is changed (e.g. by a different vCPU) between when the CPU\nexecutes the instruction and when KVM decodes the instruction to get the\nnext RIP.\n\nAs effectively predicted by commit 6ef88d6e36c2 (\u0026quot;KVM: SVM: Re-inject\nINT3/INTO instead of retrying the instruction\u0026quot;), failure to verify that\nthe correct INTn instruction was decoded can effectively clobber guest\nstate due to decoding the wrong instruction and thus specifying the\nwrong next RIP.\n\nThe bug most often manifests as \u0026quot;Oops: int3\u0026quot; panics on static branch\nchecks in Linux guests.  Enabling or disabling a static branch in Linux\nuses the kernel\u0026apos;s \u0026quot;text poke\u0026quot; code patching mechanism.  To modify code\nwhile other CPUs may be executing that code, Linux (temporarily)\nreplaces the first byte of the original instruction with an int3 (opcode\n0xcc), then patches in the new code stream except for the first byte,\nand finally replaces the int3 with the first byte of the new code\nstream.  If a CPU hits the int3, i.e. executes the code while it\u0026apos;s being\nmodified, then the guest kernel must look up the RIP to determine how to\nhandle the #BP, e.g. by emulating the new instruction.  If the RIP is\nincorrect, then this lookup fails and the guest kernel panics.\n\nThe bug reproduces almost instantly by hacking the guest kernel to\nrepeatedly check a static branch[1] while running a drgn script[2] on\nthe host to constantly swap out the memory containing the guest\u0026apos;s TSS.\n\n[1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a\n[2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b(CVE-2025-68259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: add i_data_sem protection in ext4_destroy_inline_data_nolock()\n\nFix a race between inline data destruction and block mapping.\n\nThe function ext4_destroy_inline_data_nolock() changes the inode data\nlayout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS.\nAt the same time, another thread may execute ext4_map_blocks(), which\ntests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks()\nor ext4_ind_map_blocks().\n\nWithout i_data_sem protection, ext4_ind_map_blocks() may receive inode\nwith EXT4_INODE_EXTENTS flag and triggering assert.\n\nkernel BUG at fs/ext4/indirect.c:546!\nEXT4-fs (loop2): unmounting filesystem.\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\nRIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681\n _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822\n ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124\n ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255\n ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000\n generic_perform_write+0x259/0x5d0 mm/filemap.c:3846\n ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285\n ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679\n call_write_iter include/linux/fs.h:2271 [inline]\n do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735\n do_iter_write+0x186/0x710 fs/read_write.c:861\n vfs_iter_write+0x70/0xa0 fs/read_write.c:902\n iter_file_splice_write+0x73b/0xc90 fs/splice.c:685\n do_splice_from fs/splice.c:763 [inline]\n direct_splice_actor+0x10f/0x170 fs/splice.c:950\n splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896\n do_splice_direct+0x1a9/0x280 fs/splice.c:1002\n do_sendfile+0xb13/0x12c0 fs/read_write.c:1255\n __do_sys_sendfile64 fs/read_write.c:1323 [inline]\n __se_sys_sendfile64 fs/read_write.c:1309 [inline]\n __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2025-68261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: refresh inline data size before write operations\n\nThe cached ei-\u0026gt;i_inline_size can become stale between the initial size\ncheck and when ext4_update_inline_data()/ext4_create_inline_data() use\nit. Although ext4_get_max_inline_size() reads the correct value at the\ntime of the check, concurrent xattr operations can modify i_inline_size\nbefore ext4_write_lock_xattr() is acquired.\n\nThis causes ext4_update_inline_data() and ext4_create_inline_data() to\nwork with stale capacity values, leading to a BUG_ON() crash in\next4_write_inline_data():\n\n  kernel BUG at fs/ext4/inline.c:1331!\n  BUG_ON(pos + len \u0026gt; EXT4_I(inode)-\u0026gt;i_inline_size);\n\nThe race window:\n1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)\n2. Size check passes for 50-byte write\n3. [Another thread adds xattr, i_inline_size changes to 40]\n4. ext4_write_lock_xattr() acquires lock\n5. ext4_update_inline_data() uses stale i_inline_size = 60\n6. Attempts to write 50 bytes but only 40 bytes actually available\n7. BUG_ON() triggers\n\nFix this by recalculating i_inline_size via ext4_find_inline_data_nolock()\nimmediately after acquiring xattr_sem. This ensures ext4_update_inline_data()\nand ext4_create_inline_data() work with current values that are protected\nfrom concurrent modifications.\n\nThis is similar to commit a54c4613dac1 (\u0026quot;ext4: fix race writing to an\ninline_data file while its xattrs are changing\u0026quot;) which fixed i_inline_off\nstaleness. This patch addresses the related i_inline_size staleness issue.(CVE-2025-68264)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: fix admin request_queue lifetime\n\nThe namespaces can access the controller\u0026apos;s admin request_queue, and\nstale references on the namespaces may exist after tearing down the\ncontroller. Ensure the admin request_queue is active by moving the\ncontroller\u0026apos;s \u0026apos;put\u0026apos; to after all controller references have been released\nto ensure no one is can access the request_queue. This fixes a reported\nuse-after-free bug:\n\n  BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0\n  Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287\n  CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G            E       6.13.2-ga1582f1a031e #15\n  Tainted: [E]=UNSIGNED_MODULE\n  Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x4f/0x60\n   print_report+0xc4/0x620\n   ? _raw_spin_lock_irqsave+0x70/0xb0\n   ? _raw_read_unlock_irqrestore+0x30/0x30\n   ? blk_queue_enter+0x41c/0x4a0\n   kasan_report+0xab/0xe0\n   ? blk_queue_enter+0x41c/0x4a0\n   blk_queue_enter+0x41c/0x4a0\n   ? __irq_work_queue_local+0x75/0x1d0\n   ? blk_queue_start_drain+0x70/0x70\n   ? irq_work_queue+0x18/0x20\n   ? vprintk_emit.part.0+0x1cc/0x350\n   ? wake_up_klogd_work_func+0x60/0x60\n   blk_mq_alloc_request+0x2b7/0x6b0\n   ? __blk_mq_alloc_requests+0x1060/0x1060\n   ? __switch_to+0x5b7/0x1060\n   nvme_submit_user_cmd+0xa9/0x330\n   nvme_user_cmd.isra.0+0x240/0x3f0\n   ? force_sigsegv+0xe0/0xe0\n   ? nvme_user_cmd64+0x400/0x400\n   ? vfs_fileattr_set+0x9b0/0x9b0\n   ? cgroup_update_frozen_flag+0x24/0x1c0\n   ? cgroup_leave_frozen+0x204/0x330\n   ? nvme_ioctl+0x7c/0x2c0\n   blkdev_ioctl+0x1a8/0x4d0\n   ? blkdev_common_ioctl+0x1930/0x1930\n   ? fdget+0x54/0x380\n   __x64_sys_ioctl+0x129/0x190\n   do_syscall_64+0x5b/0x160\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n  RIP: 0033:0x7f765f703b0b\n  Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48\n  RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010\n  RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b\n  RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003\n  RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000\n  R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003\n  R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60\n   \u0026lt;/TASK\u0026gt;(CVE-2025-68265)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix crash in process_v2_sparse_read() for encrypted directories\n\nThe crash in process_v2_sparse_read() for fscrypt-encrypted directories\nhas been reported. Issue takes place for Ceph msgr2 protocol in secure\nmode. It can be reproduced by the steps:\n\nsudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure\n\n(1) mkdir /mnt/cephfs/fscrypt-test-3\n(2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3\n(3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3\n(4) fscrypt lock /mnt/cephfs/fscrypt-test-3\n(5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3\n(6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar\n(7) Issue has been triggered\n\n[  408.072247] ------------[ cut here ]------------\n[  408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865\nceph_con_v2_try_read+0x4b39/0x72f0\n[  408.072267] Modules linked in: intel_rapl_msr intel_rapl_common\nintel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery\npmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass\npolyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse\nserio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg\npata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore\n[  408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+\n[  408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.17.0-5.fc42 04/01/2014\n[  408.072310] Workqueue: ceph-msgr ceph_con_workfn\n[  408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0\n[  408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8\n8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff \u0026lt;0f\u0026gt; 0b e9 06\nfe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85\n[  408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246\n[  408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38\n[  408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n[  408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8\n[  408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8\n[  408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000\n[  408.072329] FS:  0000000000000000(0000) GS:ffff88823eadf000(0000)\nknlGS:0000000000000000\n[  408.072331] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0\n[  408.072336] PKRU: 55555554\n[  408.072337] Call Trace:\n[  408.072338]  \u0026lt;TASK\u0026gt;\n[  408.072340]  ? sched_clock_noinstr+0x9/0x10\n[  408.072344]  ? __pfx_ceph_con_v2_try_read+0x10/0x10\n[  408.072347]  ? _raw_spin_unlock+0xe/0x40\n[  408.072349]  ? finish_task_switch.isra.0+0x15d/0x830\n[  408.072353]  ? __kasan_check_write+0x14/0x30\n[  408.072357]  ? mutex_lock+0x84/0xe0\n[  408.072359]  ? __pfx_mutex_lock+0x10/0x10\n[  408.072361]  ceph_con_workfn+0x27e/0x10e0\n[  408.072364]  ? metric_delayed_work+0x311/0x2c50\n[  408.072367]  process_one_work+0x611/0xe20\n[  408.072371]  ? __kasan_check_write+0x14/0x30\n[  408.072373]  worker_thread+0x7e3/0x1580\n[  408.072375]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[  408.072378]  ? __pfx_worker_thread+0x10/0x10\n[  408.072381]  kthread+0x381/0x7a0\n[  408.072383]  ? __pfx__raw_spin_lock_irq+0x10/0x10\n[  408.072385]  ? __pfx_kthread+0x10/0x10\n[  408.072387]  ? __kasan_check_write+0x14/0x30\n[  408.072389]  ? recalc_sigpending+0x160/0x220\n[  408.072392]  ? _raw_spin_unlock_irq+0xe/0x50\n[  408.072394]  ? calculate_sigpending+0x78/0xb0\n[  408.072395]  ? __pfx_kthread+0x10/0x10\n[  408.072397]  ret_from_fork+0x2b6/0x380\n[  408.072400]  ? __pfx_kthread+0x10/0x10\n[  408.072402]  ret_from_fork_asm+0x1a/0x30\n[  408.072406]  \u0026lt;/TASK\u0026gt;\n[  408.072407] ---[ end trace 0000000000000000 ]---\n[  408.072418] Oops: general protection fault, probably for non-canonical\naddress 0xdffffc00000000\n---truncated---(CVE-2025-68297)\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\u0026apos;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-\u0026gt;len \u0026gt; 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 \u0026lt;48\u0026gt; 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\u0026lt;IRQ\u0026gt;\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-\u0026gt;len \u0026gt; AQ_CFG_RX_HDR_SIZE,\n  then all fragments are accounted for.(CVE-2025-68301)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI/AER: Fix NULL pointer access by aer_info\n\nThe kzalloc(GFP_KERNEL) may return NULL, so all accesses to aer_info-\u0026gt;xxx\nwill result in kernel panic. Fix it.(CVE-2025-68309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer\n\nWhen a UAS device is unplugged during data transfer, there is\na probability of a system panic occurring. The root cause is\nan access to an invalid memory address during URB callback handling.\nSpecifically, this happens when the dma_direct_unmap_sg() function\nis called within the usb_hcd_unmap_urb_for_dma() interface, but the\nsg-\u0026gt;dma_address field is 0 and the sg data structure has already been\nfreed.\n\nThe SCSI driver sends transfer commands by invoking uas_queuecommand_lck()\nin uas.c, using the uas_submit_urbs() function to submit requests to USB.\nWithin the uas_submit_urbs() implementation, three URBs (sense_urb,\ndata_urb, and cmd_urb) are sequentially submitted. Device removal may\noccur at any point during uas_submit_urbs execution, which may result\nin URB submission failure. However, some URBs might have been successfully\nsubmitted before the failure, and uas_submit_urbs will return the -ENODEV\nerror code in this case. The current error handling directly calls\nscsi_done(). In the SCSI driver, this eventually triggers scsi_complete()\nto invoke scsi_end_request() for releasing the sgtable. The successfully\nsubmitted URBs, when being unlinked to giveback, call\nusb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg\nunmapping operations since the sg data structure has already been freed.\n\nThis patch modifies the error condition check in the uas_submit_urbs()\nfunction. When a UAS device is removed but one or more URBs have already\nbeen successfully submitted to USB, it avoids immediately invoking\nscsi_done() and save the cmnd to devinfo-\u0026gt;cmnd array. If the successfully\nsubmitted URBs is completed before devinfo-\u0026gt;resetting being set, then\nthe scsi_done() function will be called within uas_try_complete() after\nall pending URB operations are finalized. Otherwise, the scsi_done()\nfunction will be called within uas_zap_pending(), which is executed after\nusb_kill_anchored_urbs().\n\nThe error handling only takes effect when uas_queuecommand_lck() calls\nuas_submit_urbs() and returns the error value -ENODEV . In this case,\nthe device is disconnected, and the flow proceeds to uas_disconnect(),\nwhere uas_zap_pending() is invoked to call uas_try_complete().(CVE-2025-68331)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corrupted\n\nThere\u0026apos;s issue when file system corrupted:\n------------[ cut here ]------------\nkernel BUG at fs/jbd2/transaction.c:1289!\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-next\nRIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0\nRSP: 0018:ffff888117aafa30 EFLAGS: 00010202\nRAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534\nRDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010\nRBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028\nR10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000\nR13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __ext4_journal_get_create_access+0x42/0x170\n ext4_getblk+0x319/0x6f0\n ext4_bread+0x11/0x100\n ext4_append+0x1e6/0x4a0\n ext4_init_new_dir+0x145/0x1d0\n ext4_mkdir+0x326/0x920\n vfs_mkdir+0x45c/0x740\n do_mkdirat+0x234/0x2f0\n __x64_sys_mkdir+0xd6/0x120\n do_syscall_64+0x5f/0xfa0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe above issue occurs with us in errors=continue mode when accompanied by\nstorage failures. There have been many inconsistencies in the file system\ndata.\nIn the case of file system data inconsistency, for example, if the block\nbitmap of a referenced block is not set, it can lead to the situation where\na block being committed is allocated and used again. As a result, the\nfollowing condition will not be satisfied then trigger BUG_ON. Of course,\nit is entirely possible to construct a problematic image that can trigger\nthis BUG_ON through specific operations. In fact, I have constructed such\nan image and easily reproduced this issue.\nTherefore, J_ASSERT() holds true only under ideal conditions, but it may\nnot necessarily be satisfied in exceptional scenarios. Using J_ASSERT()\ndirectly in abnormal situations would cause the system to crash, which is\nclearly not what we want. So here we directly trigger a JBD abort instead\nof immediately invoking BUG_ON.(CVE-2025-68337)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid\n\nFixes a crash when layout is null during this call stack:\n\nwrite_inode\n    -\u0026gt; nfs4_write_inode\n        -\u0026gt; pnfs_layoutcommit_inode\n\npnfs_set_layoutcommit relies on the lseg refcount to keep the layout\naround. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt\nto reference a null layout.(CVE-2025-68349)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: core: Protect regulator_supply_alias_list with regulator_list_mutex\n\nregulator_supply_alias_list was accessed without any locking in\nregulator_supply_alias(), regulator_register_supply_alias(), and\nregulator_unregister_supply_alias(). Concurrent registration,\nunregistration and lookups can race, leading to:\n\n1 use-after-free if an alias entry is removed while being read,\n2 duplicate entries when two threads register the same alias,\n3 inconsistent alias mappings observed by consumers.\n\nProtect all traversals, insertions and deletions on\nregulator_supply_alias_list with the existing regulator_list_mutex.(CVE-2025-68354)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Prevent recursive memory reclaim\n\nFunction new_inode() returns a new inode with inode-\u0026gt;i_mapping-\u0026gt;gfp_mask\nset to GFP_HIGHUSER_MOVABLE.  This value includes the __GFP_FS flag, so\nallocations in that address space can recurse into filesystem memory\nreclaim.  We don\u0026apos;t want that to happen because it can consume a\nsignificant amount of stack memory.\n\nWorse than that is that it can also deadlock: for example, in several\nplaces, gfs2_unstuff_dinode() is called inside filesystem transactions.\nThis calls filemap_grab_folio(), which can allocate a new folio, which\ncan trigger memory reclaim.  If memory reclaim recurses into the\nfilesystem and starts another transaction, a deadlock will ensue.\n\nTo fix these kinds of problems, prevent memory reclaim from recursing\ninto filesystem code by making sure that the gfp_mask of inode address\nspaces doesn\u0026apos;t include __GFP_FS.\n\nThe \u0026quot;meta\u0026quot; and resource group address spaces were already using GFP_NOFS\nas their gfp_mask (which doesn\u0026apos;t include __GFP_FS).  The default value\nof GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though.  To\navoid being overly limiting, use the default value and only knock off\nthe __GFP_FS flag.  I\u0026apos;m not sure if this will actually make a\ndifference, but it also shouldn\u0026apos;t hurt.\n\nThis patch is loosely based on commit ad22c7a043c2 (\u0026quot;xfs: prevent stack\noverflows from page cache allocation\u0026quot;).\n\nFixes xfstest generic/273.(CVE-2025-68356)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()\n\nThe rtl8187_rx_cb() calculates the rx descriptor header address\nby subtracting its size from the skb tail pointer.\nHowever, it does not validate if the received packet\n(skb-\u0026gt;len from urb-\u0026gt;actual_length) is large enough to contain this\nheader.\n\nIf a truncated packet is received, this will lead to a buffer\nunderflow, reading memory before the start of the skb data area,\nand causing a kernel panic.\n\nAdd length checks for both rtl8187 and rtl8187b descriptor headers\nbefore attempting to access them, dropping the packet cleanly if the\ncheck fails.(CVE-2025-68362)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Check skb-\u0026gt;transport_header is set in bpf_skb_check_mtu\n\nThe bpf_skb_check_mtu helper needs to use skb-\u0026gt;transport_header when\nthe BPF_MTU_CHK_SEGS flag is used:\n\n\tbpf_skb_check_mtu(skb, ifindex, \u0026amp;mtu_len, 0, BPF_MTU_CHK_SEGS)\n\nThe transport_header is not always set. There is a WARN_ON_ONCE\nreport when CONFIG_DEBUG_NET is enabled + skb-\u0026gt;gso_size is set +\nbpf_prog_test_run is used:\n\nWARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071\n skb_gso_validate_network_len\n bpf_skb_check_mtu\n bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch\n bpf_test_run\n bpf_prog_test_run_skb\n\nFor a normal ingress skb (not test_run), skb_reset_transport_header\nis performed but there is plan to avoid setting it as described in\ncommit 2170a1f09148 (\u0026quot;net: no longer reset transport_header in __netif_receive_skb_core()\u0026quot;).\n\nThis patch fixes the bpf helper by checking\nskb_transport_header_was_set(). The check is done just before\nskb-\u0026gt;transport_header is used, to avoid breaking the existing bpf prog.\nThe WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.(CVE-2025-68363)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncoresight: ETR: Fix ETR buffer use-after-free issue\n\nWhen ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed\nand enabled again, currently sysfs_buf will point to the newly\nallocated memory(buf_new) and free the old memory(buf_old). But the\netr_buf that is being used by the ETR remains pointed to buf_old, not\nupdated to buf_new. In this case, it will result in a memory\nuse-after-free issue.\n\nFix this by checking ETR\u0026apos;s mode before updating and releasing buf_old,\nif the mode is CS_MODE_SYSFS, then skip updating and releasing it.(CVE-2025-68376)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix stackmap overflow check in __bpf_get_stackid()\n\nSyzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()\nwhen copying stack trace data. The issue occurs when the perf trace\n contains more stack entries than the stack map bucket can hold,\n leading to an out-of-bounds write in the bucket\u0026apos;s data array.(CVE-2025-68378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id\n\nUse check_add_overflow() to guard against potential integer overflows\nwhen adding the binary blob lengths and the size of an asymmetric_key_id\nstructure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a\npossible buffer overflow when copying data from potentially malicious\nX.509 certificate fields that can be arbitrarily large, such as ASN.1\nINTEGER serial numbers, issuer names, etc.(CVE-2025-68724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Do not let BPF test infra emit invalid GSO types to stack\n\nYinhao et al. reported that their fuzzer tool was able to trigger a\nskb_warn_bad_offload() from netif_skb_features() -\u0026gt; gso_features_check().\nWhen a BPF program - triggered via BPF test infra - pushes the packet\nto the loopback device via bpf_clone_redirect() then mentioned offload\nwarning can be seen. GSO-related features are then rightfully disabled.\n\nWe get into this situation due to convert___skb_to_skb() setting\ngso_segs and gso_size but not gso_type. Technically, it makes sense\nthat this warning triggers since the GSO properties are malformed due\nto the gso_type. Potentially, the gso_type could be marked non-trustworthy\nthrough setting it at least to SKB_GSO_DODGY without any other specific\nassumptions, but that also feels wrong given we should not go further\ninto the GSO engine in the first place.\n\nThe checks were added in 121d57af308d (\u0026quot;gso: validate gso_type in GSO\nhandlers\u0026quot;) because there were malicious (syzbot) senders that combine\na protocol with a non-matching gso_type. If we would want to drop such\npackets, gso_features_check() currently only returns feature flags via\nnetif_skb_features(), so one location for potentially dropping such skbs\ncould be validate_xmit_unreadable_skb(), but then otoh it would be\nan additional check in the fast-path for a very corner case. Given\nbpf_clone_redirect() is the only place where BPF test infra could emit\nsuch packets, lets reject them right there.(CVE-2025-68725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nisdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()\n\nIn hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when\nsetup_instance() fails with an error code. Fix that by freeing the urb\nbefore freeing the hw structure. Also change the error paths to use the\ngoto ladder style.\n\nCompile tested only. Issue found using a prototype static analysis tool.(CVE-2025-68734)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix improper freeing of purex item\n\nIn qla2xxx_process_purls_iocb(), an item is allocated via\nqla27xx_copy_multiple_pkt(), which internally calls\nqla24xx_alloc_purex_item().\n\nThe qla24xx_alloc_purex_item() function may return a pre-allocated item\nfrom a per-adapter pool for small allocations, instead of dynamically\nallocating memory with kzalloc().\n\nAn error handling path in qla2xxx_process_purls_iocb() incorrectly uses\nkfree() to release the item. If the item was from the pre-allocated\npool, calling kfree() on it is a bug that can lead to memory corruption.\n\nFix this by using the correct deallocation function,\nqla24xx_free_purex_item(), which properly handles both dynamically\nallocated and pre-allocated items.(CVE-2025-68741)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Free special fields when update [lru_,]percpu_hash maps\n\nAs [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing\ncalls to \u0026apos;bpf_obj_free_fields()\u0026apos; in \u0026apos;pcpu_copy_value()\u0026apos; could cause the\nmemory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the\nmap gets freed.\n\nFix this by calling \u0026apos;bpf_obj_free_fields()\u0026apos; after\n\u0026apos;copy_map_value[,_long]()\u0026apos; in \u0026apos;pcpu_copy_value()\u0026apos;.(CVE-2025-68744)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Clear cmds after chip reset\n\nCommit aefed3e5548f (\u0026quot;scsi: qla2xxx: target: Fix offline port handling\nand host reset handling\u0026quot;) caused two problems:\n\n1. Commands sent to FW, after chip reset got stuck and never freed as FW\n   is not going to respond to them anymore.\n\n2. BUG_ON(cmd-\u0026gt;sg_mapped) in qlt_free_cmd().  Commit 26f9ce53817a\n   (\u0026quot;scsi: qla2xxx: Fix missed DMA unmap for aborted commands\u0026quot;)\n   attempted to fix this, but introduced another bug under different\n   circumstances when two different CPUs were racing to call\n   qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in\n   dma_unmap_sg_attrs().\n\nSo revert \u0026quot;scsi: qla2xxx: Fix missed DMA unmap for aborted commands\u0026quot; and\npartially revert \u0026quot;scsi: qla2xxx: target: Fix offline port handling and\nhost reset handling\u0026quot; at __qla2x00_abort_all_cmds.(CVE-2025-68745)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock: Use RCU in blk_mq_[un]quiesce_tagset() instead of set-\u0026gt;tag_list_lock\n\nblk_mq_{add,del}_queue_tag_set() functions add and remove queues from\ntagset, the functions make sure that tagset and queues are marked as\nshared when two or more queues are attached to the same tagset.\nInitially a tagset starts as unshared and when the number of added\nqueues reaches two, blk_mq_add_queue_tag_set() marks it as shared along\nwith all the queues attached to it. When the number of attached queues\ndrops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and\nthe remaining queues as unshared.\n\nBoth functions need to freeze current queues in tagset before setting on\nunsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions\nhold set-\u0026gt;tag_list_lock mutex, which makes sense as we do not want\nqueues to be added or deleted in the process. This used to work fine\nuntil commit 98d81f0df70c (\u0026quot;nvme: use blk_mq_[un]quiesce_tagset\u0026quot;)\nmade the nvme driver quiesce tagset instead of quiscing individual\nqueues. blk_mq_quiesce_tagset() does the job and quiesce the queues in\nset-\u0026gt;tag_list while holding set-\u0026gt;tag_list_lock also.\n\nThis results in deadlock between two threads with these stacktraces:\n\n  __schedule+0x47c/0xbb0\n  ? timerqueue_add+0x66/0xb0\n  schedule+0x1c/0xa0\n  schedule_preempt_disabled+0xa/0x10\n  __mutex_lock.constprop.0+0x271/0x600\n  blk_mq_quiesce_tagset+0x25/0xc0\n  nvme_dev_disable+0x9c/0x250\n  nvme_timeout+0x1fc/0x520\n  blk_mq_handle_expired+0x5c/0x90\n  bt_iter+0x7e/0x90\n  blk_mq_queue_tag_busy_iter+0x27e/0x550\n  ? __blk_mq_complete_request_remote+0x10/0x10\n  ? __blk_mq_complete_request_remote+0x10/0x10\n  ? __call_rcu_common.constprop.0+0x1c0/0x210\n  blk_mq_timeout_work+0x12d/0x170\n  process_one_work+0x12e/0x2d0\n  worker_thread+0x288/0x3a0\n  ? rescuer_thread+0x480/0x480\n  kthread+0xb8/0xe0\n  ? kthread_park+0x80/0x80\n  ret_from_fork+0x2d/0x50\n  ? kthread_park+0x80/0x80\n  ret_from_fork_asm+0x11/0x20\n\n  __schedule+0x47c/0xbb0\n  ? xas_find+0x161/0x1a0\n  schedule+0x1c/0xa0\n  blk_mq_freeze_queue_wait+0x3d/0x70\n  ? destroy_sched_domains_rcu+0x30/0x30\n  blk_mq_update_tag_set_shared+0x44/0x80\n  blk_mq_exit_queue+0x141/0x150\n  del_gendisk+0x25a/0x2d0\n  nvme_ns_remove+0xc9/0x170\n  nvme_remove_namespaces+0xc7/0x100\n  nvme_remove+0x62/0x150\n  pci_device_remove+0x23/0x60\n  device_release_driver_internal+0x159/0x200\n  unbind_store+0x99/0xa0\n  kernfs_fop_write_iter+0x112/0x1e0\n  vfs_write+0x2b1/0x3d0\n  ksys_write+0x4e/0xb0\n  do_syscall_64+0x5b/0x160\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nThe top stacktrace is showing nvme_timeout() called to handle nvme\ncommand timeout. timeout handler is trying to disable the controller and\nas a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not\nto call queue callback handlers. The thread is stuck waiting for\nset-\u0026gt;tag_list_lock as it tries to walk the queues in set-\u0026gt;tag_list.\n\nThe lock is held by the second thread in the bottom stack which is\nwaiting for one of queues to be frozen. The queue usage counter will\ndrop to zero after nvme_timeout() finishes, and this will not happen\nbecause the thread will wait for this mutex forever.\n\nGiven that [un]quiescing queue is an operation that does not need to\nsleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking\nset-\u0026gt;tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU\nsafe list operations. Also, delete INIT_LIST_HEAD(\u0026amp;q-\u0026gt;tag_set_list)\nin blk_mq_del_queue_tag_set() because we can not re-initialize it while\nthe list is being traversed under RCU. The deleted queue will not be\nadded/deleted to/from a tagset and it will be freed in blk_free_queue()\nafter the end of RCU grace period.(CVE-2025-68756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/deadline: only set free_cpus for online runqueues\n\nCommit 16b269436b72 (\u0026quot;sched/deadline: Modify cpudl::free_cpus\nto reflect rd-\u0026gt;online\u0026quot;) introduced the cpudl_set/clear_freecpu\nfunctions to allow the cpu_dl::free_cpus mask to be manipulated\nby the deadline scheduler class rq_on/offline callbacks so the\nmask would also reflect this state.\n\nCommit 9659e1eeee28 (\u0026quot;sched/deadline: Remove cpu_active_mask\nfrom cpudl_find()\u0026quot;) removed the check of the cpu_active_mask to\nsave some processing on the premise that the cpudl::free_cpus\nmask already reflected the runqueue online state.\n\nUnfortunately, there are cases where it is possible for the\ncpudl_clear function to set the free_cpus bit for a CPU when the\ndeadline runqueue is offline. When this occurs while a CPU is\nconnected to the default root domain the flag may retain the bad\nstate after the CPU has been unplugged. Later, a different CPU\nthat is transitioning through the default root domain may push a\ndeadline task to the powered down CPU when cpudl_find sees its\nfree_cpus bit is set. If this happens the task will not have the\nopportunity to run.\n\nOne example is outlined here:\nhttps://lore.kernel.org/lkml/(CVE-2025-68780)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: Reset t_task_cdb pointer in error case\n\nIf allocation of cmd-\u0026gt;t_task_cdb fails, it remains NULL but is later\ndereferenced in the \u0026apos;err\u0026apos; path.\n\nIn case of error, reset NULL t_task_cdb value to point at the default\nfixed-size buffer.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-68782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niomap: adjust read range correctly for non-block-aligned positions\n\niomap_adjust_read_range() assumes that the position and length passed in\nare block-aligned. This is not always the case however, as shown in the\nsyzbot generated case for erofs. This causes too many bytes to be\nskipped for uptodate blocks, which results in returning the incorrect\nposition and length to read in. If all the blocks are uptodate, this\nunderflows length and returns a position beyond the folio.\n\nFix the calculation to also take into account the block offset when\ncalculating how many bytes can be skipped for uptodate blocks.(CVE-2025-68794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: NFSv4 file creation neglects setting ACL\n\nAn NFSv4 client that sets an ACL with a named principal during file\ncreation retrieves the ACL afterwards, and finds that it is only a\ndefault ACL (based on the mode bits) and not the ACL that was\nrequested during file creation. This violates RFC 8881 section\n6.4.1.3: \u0026quot;the ACL attribute is set as given\u0026quot;.\n\nThe issue occurs in nfsd_create_setattr(), which calls\nnfsd_attrs_valid() to determine whether to call nfsd_setattr().\nHowever, nfsd_attrs_valid() checks only for iattr changes and\nsecurity labels, but not POSIX ACLs. When only an ACL is present,\nthe function returns false, nfsd_setattr() is skipped, and the\nPOSIX ACL is never applied to the inode.\n\nSubsequently, when the client retrieves the ACL, the server finds\nno POSIX ACL on the inode and returns one generated from the file\u0026apos;s\nmode bits rather than returning the originally-specified ACL.(CVE-2025-68803)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix filename leak in __io_openat_prep()\n\n __io_openat_prep() allocates a struct filename using getname(). However,\nfor the condition of the file being installed in the fixed file table as\nwell as having O_CLOEXEC flag set, the function returns early. At that\npoint, the request doesn\u0026apos;t have REQ_F_NEED_CLEANUP flag set. Due to this,\nthe memory for the newly allocated struct filename is not cleaned up,\ncausing a memory leak.\n\nFix this by setting the REQ_F_NEED_CLEANUP for the request just after the\nsuccessful getname() call, so that when the request is torn down, the\nfilename will be cleaned up, along with other resources needing cleanup.(CVE-2025-68814)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: fw_tracer, Validate format string parameters\n\nAdd validation for format string parameters in the firmware tracer to\nprevent potential security vulnerabilities and crashes from malformed\nformat strings received from firmware.\n\nThe firmware tracer receives format strings from the device firmware and\nuses them to format trace messages. Without proper validation, bad\nfirmware could provide format strings with invalid format specifiers\n(e.g., %s, %p, %n) that could lead to crashes, or other undefined\nbehavior.\n\nAdd mlx5_tracer_validate_params() to validate that all format specifiers\nin trace strings are limited to safe integer/hex formats (%x, %d, %i,\n%u, %llx, %lx, etc.). Reject strings containing other format types that\ncould be used to access arbitrary memory or cause crashes.\nInvalid format strings are added to the trace output for visibility with\n\u0026quot;BAD_FORMAT: \u0026quot; prefix.(CVE-2025-68816)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: Revert \u0026quot;scsi: qla2xxx: Perform lockless command completion in abort path\u0026quot;\n\nThis reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.\n\nThe commit being reverted added code to __qla2x00_abort_all_cmds() to\ncall sp-\u0026gt;done() without holding a spinlock.  But unlike the older code\nbelow it, this new code failed to check sp-\u0026gt;cmd_type and just assumed\nTYPE_SRB, which results in a jump to an invalid pointer in target-mode\nwith TYPE_TGT_CMD:\n\nqla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success\n  0000000009f7a79b\nqla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h\n  mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.\nqla2xxx [0000:65:00.0]-d01e:8: -\u0026gt; fwdump no buffer\nqla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event\n  0x8002 occurred\nqla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery -\n  ha=0000000058183fda.\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPF: supervisor instruction fetch in kernel mode\nPF: error_code(0x0010) - not-present page\nPGD 0 P4D 0\nOops: 0010 [#1] SMP\nCPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G           O       6.1.133 #1\nHardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023\nRIP: 0010:0x0\nCode: Unable to access opcode bytes at 0xffffffffffffffd6.\nRSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206\nRAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000\nRDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0\nRBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045\nR10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40\nR13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400\nFS:  0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x4d/0x8b\n ? page_fault_oops+0x91/0x180\n ? trace_buffer_unlock_commit_regs+0x38/0x1a0\n ? exc_page_fault+0x391/0x5e0\n ? asm_exc_page_fault+0x22/0x30\n __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst]\n qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst]\n qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst]\n qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst]\n qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst]\n kthread+0xa8/0xd0\n \u0026lt;/TASK\u0026gt;\n\nThen commit 4475afa2646d (\u0026quot;scsi: qla2xxx: Complete command early within\nlock\u0026quot;) added the spinlock back, because not having the lock caused a\nrace and a crash.  But qla2x00_abort_srb() in the switch below already\nchecks for qla2x00_chip_is_down() and handles it the same way, so the\ncode above the switch is now redundant and still buggy in target-mode.\nRemove it.(CVE-2025-68818)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nshmem: fix recovery on rename failures\n\nmaple_tree insertions can fail if we are seriously short on memory;\nsimple_offset_rename() does not recover well if it runs into that.\nThe same goes for simple_offset_rename_exchange().\n\nMoreover, shmem_whiteout() expects that if it succeeds, the caller will\nprogress to d_move(), i.e. that shmem_rename2() won\u0026apos;t fail past the\nsuccessful call of shmem_whiteout().\n\nNot hard to fix, fortunately - mtree_store() can\u0026apos;t fail if the index we\nare trying to store into is already present in the tree as a singleton.\n\nFor simple_offset_rename_exchange() that\u0026apos;s enough - we just need to be\ncareful about the order of operations.\n\nFor simple_offset_rename() solution is to preinsert the target into the\ntree for new_dir; the rest can be done without any potentially failing\noperations.\n\nThat preinsertion has to be done in shmem_rename2() rather than in\nsimple_offset_rename() itself - otherwise we\u0026apos;d need to deal with the\npossibility of failure after successful shmem_whiteout().(CVE-2025-71072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer\n\nWhen advancing the target expiration for the guest\u0026apos;s APIC timer in periodic\nmode, set the expiration to \u0026quot;now\u0026quot; if the target expiration is in the past\n(similar to what is done in update_target_expiration()).  Blindly adding\nthe period to the previous target expiration can result in KVM generating\na practically unbounded number of hrtimer IRQs due to programming an\nexpired timer over and over.  In extreme scenarios, e.g. if userspace\npauses/suspends a VM for an extended duration, this can even cause hard\nlockups in the host.\n\nCurrently, the bug only affects Intel CPUs when using the hypervisor timer\n(HV timer), a.k.a. the VMX preemption timer.  Unlike the software timer,\na.k.a. hrtimer, which KVM keeps running even on exits to userspace, the\nHV timer only runs while the guest is active.  As a result, if the vCPU\ndoes not run for an extended duration, there will be a huge gap between\nthe target expiration and the current time the vCPU resumes running.\nBecause the target expiration is incremented by only one period on each\ntimer expiration, this leads to a series of timer expirations occurring\nrapidly after the vCPU/VM resumes.\n\nMore critically, when the vCPU first triggers a periodic HV timer\nexpiration after resuming, advancing the expiration by only one period\nwill result in a target expiration in the past.  As a result, the delta\nmay be calculated as a negative value.  When the delta is converted into\nan absolute value (tscdeadline is an unsigned u64), the resulting value\ncan overflow what the HV timer is capable of programming.  I.e. the large\nvalue will exceed the VMX Preemption Timer\u0026apos;s maximum bit width of\ncpu_preemption_timer_multi + 32, and thus cause KVM to switch from the\nHV timer to the software timer (hrtimers).\n\nAfter switching to the software timer, periodic timer expiration callbacks\nmay be executed consecutively within a single clock interrupt handler,\nbecause hrtimers honors KVM\u0026apos;s request for an expiration in the past and\nimmediately re-invokes KVM\u0026apos;s callback after reprogramming.  And because\nthe interrupt handler runs with IRQs disabled, restarting KVM\u0026apos;s hrtimer\nover and over until the target expiration is advanced to \u0026quot;now\u0026quot; can result\nin a hard lockup.\n\nE.g. the following hard lockup was triggered in the host when running a\nWindows VM (only relevant because it used the APIC timer in periodic mode)\nafter resuming the VM from a long suspend (in the host).\n\n  NMI watchdog: Watchdog detected hard LOCKUP on cpu 45\n  ...\n  RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]\n  ...\n  RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046\n  RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc\n  RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500\n  RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0\n  R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0\n  R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8\n  FS:  00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0\n  PKRU: 55555554\n  Call Trace:\n   \u0026lt;IRQ\u0026gt;\n   apic_timer_fn+0x31/0x50 [kvm]\n   __hrtimer_run_queues+0x100/0x280\n   hrtimer_interrupt+0x100/0x210\n   ? ttwu_do_wakeup+0x19/0x160\n   smp_apic_timer_interrupt+0x6a/0x130\n   apic_timer_interrupt+0xf/0x20\n   \u0026lt;/IRQ\u0026gt;\n\nMoreover, if the suspend duration of the virtual machine is not long enough\nto trigger a hard lockup in this scenario, since commit 98c25ead5eda\n(\u0026quot;KVM: VMX: Move preemption timer \u0026lt;=\u0026gt; hrtimer dance to common x86\u0026quot;), KVM\nwill continue using the software timer until the guest reprograms the APIC\ntimer in some way.  Since the periodic timer does not require frequent APIC\ntimer register programming, the guest may continue to use the software\ntimer in \n---truncated---(CVE-2025-71104)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: make decode_pool() more resilient against corrupted osdmaps\n\nIf the osdmap is (maliciously) corrupted such that the encoded length\nof ceph_pg_pool envelope is less than what is expected for a particular\nencoding version, out-of-bounds reads may ensue because the only bounds\ncheck that is there is based on that length value.\n\nThis patch adds explicit bounds checks for each field that is decoded\nor skipped.(CVE-2025-71116)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: seqiv - Do not use req-\u0026gt;iv after crypto_aead_encrypt\n\nAs soon as crypto_aead_encrypt is called, the underlying request\nmay be freed by an asynchronous completion.  Thus dereferencing\nreq-\u0026gt;iv after it returns is invalid.\n\nInstead of checking req-\u0026gt;iv against info, create a new variable\nunaligned_info and use it for that purpose instead.(CVE-2025-71131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: trusted: Fix a memory leak in tpm2_load_cmd\n\n\u0026apos;tpm2_load_cmd\u0026apos; allocates a tempoary blob indirectly via \u0026apos;tpm2_key_decode\u0026apos;\nbut it is not freed in the failure paths. Address this by wrapping the blob\ninto with a cleanup helper.(CVE-2025-71147)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/poll: correctly handle io_poll_add() return value on update\n\nWhen the core of io_uring was updated to handle completions\nconsistently and with fixed return codes, the POLL_REMOVE opcode\nwith updates got slightly broken. If a POLL_ADD is pending and\nthen POLL_REMOVE is used to update the events of that request, if that\nupdate causes the POLL_ADD to now trigger, then that completion is lost\nand a CQE is never posted.\n\nAdditionally, ensure that if an update does cause an existing POLL_ADD\nto complete, that the completion value isn\u0026apos;t always overwritten with\n-ECANCELED. For that case, whatever io_poll_add() set the value to\nshould just be retained.(CVE-2025-71149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: Fix refcount leak when invalid session is found on session lookup\n\nWhen a session is found but its state is not SMB2_SESSION_VALID, It\nindicates that no valid session was found, but it is missing to decrement\nthe reference count acquired by the session lookup, which results in\na reference count leak. This patch fixes the issue by explicitly calling\nksmbd_user_session_put to release the reference to the session.(CVE-2025-71150)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Don\u0026apos;t store mlx5e_priv in mlx5e_dev devlink priv\n\nmlx5e_priv is an unstable structure that can be memset(0) if profile\nattaching fails, mlx5e_priv in mlx5e_dev devlink private is used to\nreference the netdev and mdev associated with that struct. Instead,\nstore netdev directly into mlx5e_dev and get mdev from the containing\nmlx5_adev aux device structure.\n\nThis fixes a kernel oops in mlx5e_remove when switchdev mode fails due\nto change profile failure.\n\n$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev\nError: mlx5_core: Failed setting eswitch to offloads.\ndmesg:\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n\n$ devlink dev reload pci/0000:00:03.0 ==\u0026gt; oops\n\nBUG: kernel NULL pointer dereference, address: 0000000000000520\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_remove+0x68/0x130\nRSP: 0018:ffffc900034838f0 EFLAGS: 00010246\nRAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000\nRBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10\nR10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0\nR13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400\nFS:  00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n device_release_driver_internal+0x19c/0x200\n bus_remove_device+0xc6/0x130\n device_del+0x160/0x3d0\n ? devl_param_driverinit_value_get+0x2d/0x90\n mlx5_detach_device+0x89/0xe0\n mlx5_unload_one_devl_locked+0x3a/0x70\n mlx5_devlink_reload_down+0xc8/0x220\n devlink_reload+0x7d/0x260\n devlink_nl_reload_doit+0x45b/0x5a0\n genl_family_rcv_msg_doit+0xe8/0x140(CVE-2026-22996)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec\n\nCommit efa56305908b (\u0026quot;nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\u0026quot;)\nadded ttag bounds checking and data_offset\nvalidation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate\nwhether the command\u0026apos;s data structures (cmd-\u0026gt;req.sg and cmd-\u0026gt;iov) have\nbeen properly initialized before processing H2C_DATA PDUs.\n\nThe nvmet_tcp_build_pdu_iovec() function dereferences these pointers\nwithout NULL checks. This can be triggered by sending H2C_DATA PDU\nimmediately after the ICREQ/ICRESP handshake, before\nsending a CONNECT command or NVMe write command.\n\nAttack vectors that trigger NULL pointer dereferences:\n1. H2C_DATA PDU sent before CONNECT \u2192 both pointers NULL\n2. H2C_DATA PDU for READ command \u2192 cmd-\u0026gt;req.sg allocated, cmd-\u0026gt;iov NULL\n3. H2C_DATA PDU for uninitialized command slot \u2192 both pointers NULL\n\nThe fix validates both cmd-\u0026gt;req.sg and cmd-\u0026gt;iov before calling\nnvmet_tcp_build_pdu_iovec(). Both checks are required because:\n- Uninitialized commands: both NULL\n- READ commands: cmd-\u0026gt;req.sg allocated, cmd-\u0026gt;iov NULL\n- WRITE commands: both allocated(CVE-2026-22998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix crash on profile change rollback failure\n\nmlx5e_netdev_change_profile can fail to attach a new profile and can\nfail to rollback to old profile, in such case, we could end up with a\ndangling netdev with a fully reset netdev_priv. A retry to change\nprofile, e.g. another attempt to call mlx5e_netdev_change_profile via\nswitchdev mode change, will crash trying to access the now NULL\npriv-\u0026gt;mdev.\n\nThis fix allows mlx5e_netdev_change_profile() to handle previous\nfailures and an empty priv, by not assuming priv is valid.\n\nPass netdev and mdev to all flows requiring\nmlx5e_netdev_change_profile() and avoid passing priv.\nIn mlx5e_netdev_change_profile() check if current priv is valid, and if\nnot, just attach the new profile without trying to access the old one.\n\nThis fixes the following oops, when enabling switchdev mode for the 2nd\ntime after first time failure:\n\n ## Enabling switchdev mode first time:\n\nmlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n                                                                         ^^^^^^^^\nmlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)\n\n ## retry: Enabling switchdev mode 2nd time:\n\nmlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload\nBUG: kernel NULL pointer dereference, address: 0000000000000038\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_detach_netdev+0x3c/0x90\nCode: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 \u0026lt;48\u0026gt; 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07\nRSP: 0018:ffffc90000673890 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000\nRDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000\nRBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000\nR10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000\nR13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000\nFS:  00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlx5e_netdev_change_profile+0x45/0xb0\n mlx5e_vport_rep_load+0x27b/0x2d0\n mlx5_esw_offloads_rep_load+0x72/0xf0\n esw_offloads_enable+0x5d0/0x970\n mlx5_eswitch_enable_locked+0x349/0x430\n ? is_mp_supported+0x57/0xb0\n mlx5_devlink_eswitch_mode_set+0x26b/0x430\n devlink_nl_eswitch_set_doit+0x6f/0xf0\n genl_family_rcv_msg_doit+0xe8/0x140\n genl_rcv_msg+0x18b/0x290\n ? __pfx_devlink_nl_pre_doit+0x10/0x10\n ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10\n ? __pfx_devlink_nl_post_doit+0x10/0x10\n ? __pfx_genl_rcv_msg+0x10/0x10\n netlink_rcv_skb+0x52/0x100\n genl_rcv+0x28/0x40\n netlink_unicast+0x282/0x3e0\n ? __alloc_skb+0xd6/0x190\n netlink_sendmsg+0x1f7/0x430\n __sys_sendto+0x213/0x220\n ? __sys_recvmsg+0x6a/0xd0\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0x50/0x1f0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7fdfb8495047(CVE-2026-23000)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1\n\nWhen loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in\nresponse to a guest WRMSR, clear XFD-disabled features in the saved (or to\nbe restored) XSTATE_BV to ensure KVM doesn\u0026apos;t attempt to load state for\nfeatures that are disabled via the guest\u0026apos;s XFD.  Because the kernel\nexecutes XRSTOR with the guest\u0026apos;s XFD, saving XSTATE_BV[i]=1 with XFD[i]=1\nwill cause XRSTOR to #NM and panic the kernel.\n\nE.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV:\n\n  ------------[ cut here ]------------\n  WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848\n  Modules linked in: kvm_intel kvm irqbypass\n  CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  RIP: 0010:exc_device_not_available+0x101/0x110\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   asm_exc_device_not_available+0x1a/0x20\n  RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90\n   switch_fpu_return+0x4a/0xb0\n   kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm]\n   kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]\n   __x64_sys_ioctl+0x8f/0xd0\n   do_syscall_64+0x62/0x940\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n   \u0026lt;/TASK\u0026gt;\n  ---[ end trace 0000000000000000 ]---\n\nThis can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1,\nand a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler\u0026apos;s\ncall to fpu_update_guest_xfd().\n\nand if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE:\n\n  ------------[ cut here ]------------\n  WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867\n  Modules linked in: kvm_intel kvm irqbypass\n  CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  RIP: 0010:exc_device_not_available+0x101/0x110\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   asm_exc_device_not_available+0x1a/0x20\n  RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90\n   fpu_swap_kvm_fpstate+0x6b/0x120\n   kvm_load_guest_fpu+0x30/0x80 [kvm]\n   kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm]\n   kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]\n   __x64_sys_ioctl+0x8f/0xd0\n   do_syscall_64+0x62/0x940\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n   \u0026lt;/TASK\u0026gt;\n  ---[ end trace 0000000000000000 ]---\n\nThe new behavior is consistent with the AMX architecture.  Per Intel\u0026apos;s SDM,\nXSAVE saves XSTATE_BV as \u0026apos;0\u0026apos; for components that are disabled via XFD\n(and non-compacted XSAVE saves the initial configuration of the state\ncomponent):\n\n  If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i,\n  the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1;\n  instead, it operates as if XINUSE[i] = 0 (and the state component was\n  in its initial state): it saves bit i of XSTATE_BV field of the XSAVE\n  header as 0; in addition, XSAVE saves the initial configuration of the\n  state component (the other instructions do not save state component i).\n\nAlternatively, KVM could always do XRSTOR with XFD=0, e.g. by using\na constant XFD based on the set of enabled features when XSAVEing for\na struct fpu_guest.  However, having XSTATE_BV[i]=1 for XFD-disabled\nfeatures can only happen in the above interrupt case, or in similar\nscenarios involving preemption on preemptible kernels, because\nfpu_swap_kvm_fpstate()\u0026apos;s call to save_fpregs_to_fpstate() saves the\noutgoing FPU state with the current XFD; and that is (on all but the\nfirst WRMSR to XFD) the guest XFD.\n\nTherefore, XFD can only go out of sync with XSTATE_BV in the above\ninterrupt case, or in similar scenarios involving preemption on\npreemptible kernels, and it we can consider it (de facto) part of KVM\nABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.\n\n[Move clea\n---truncated---(CVE-2026-23005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv\n\nmlx5e_priv is an unstable structure that can be memset(0) if profile\nattaching fails.\n\nPass netdev to mlx5e_destroy_netdev() to guarantee it will work on a\nvalid netdev.\n\nOn mlx5e_remove: Check validity of priv-\u0026gt;profile, before attempting\nto cleanup any resources that might be not there.\n\nThis fixes a kernel oops in mlx5e_remove when switchdev mode fails due\nto change profile failure.\n\n$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev\nError: mlx5_core: Failed setting eswitch to offloads.\ndmesg:\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n\n$ devlink dev reload pci/0000:00:03.0 ==\u0026gt; oops\n\nBUG: kernel NULL pointer dereference, address: 0000000000000370\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100\nRSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286\nRAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0\nRBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10\nR10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0\nR13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400\nFS:  00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlx5e_remove+0x57/0x110\n device_release_driver_internal+0x19c/0x200\n bus_remove_device+0xc6/0x130\n device_del+0x160/0x3d0\n ? devl_param_driverinit_value_get+0x2d/0x90\n mlx5_detach_device+0x89/0xe0\n mlx5_unload_one_devl_locked+0x3a/0x70\n mlx5_devlink_reload_down+0xc8/0x220\n devlink_reload+0x7d/0x260\n devlink_nl_reload_doit+0x45b/0x5a0\n genl_family_rcv_msg_doit+0xe8/0x140(CVE-2026-23035)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Add recursion protection in kernel stack trace recording\n\nA bug was reported about an infinite recursion caused by tracing the rcu\nevents with the kernel stack trace trigger enabled. The stack trace code\ncalled back into RCU which then called the stack trace again.\n\nExpand the ftrace recursion protection to add a set of bits to protect\nevents from recursion. Each bit represents the context that the event is\nin (normal, softirq, interrupt and NMI).\n\nHave the stack trace code use the interrupt context to protect against\nrecursion.\n\nNote, the bug showed an issue in both the RCU code as well as the tracing\nstacktrace code. This only handles the tracing stack trace side of the\nbug. The RCU fix will be handled separately.(CVE-2026-23138)",
  "id": "OESA-2026-1761",
  "modified": "2026-08-06T11:10:47Z",
  "published": "2026-03-27T11:10:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1761"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53232"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37900"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38083"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38373"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38556"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38591"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38659"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38730"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39713"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39961"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40030"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40096"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40215"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40220"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40237"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40242"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40251"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40271"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40272"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40277"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40294"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40301"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40308"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40318"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40341"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40342"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40343"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40346"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40351"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40358"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40359"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40361"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68171"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68173"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68174"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68176"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68188"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68200"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68206"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68208"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68235"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68259"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68261"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68264"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68265"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68297"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68301"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68309"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68331"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68337"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68349"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68354"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68356"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68362"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68363"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68376"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68378"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68724"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68725"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68734"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68741"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68744"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68745"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68756"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68780"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68782"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68794"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68803"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68814"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68816"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68818"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71072"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71104"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71116"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71131"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71147"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71149"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71150"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22996"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22998"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23000"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23005"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23035"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23138"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-53232",
    "CVE-2025-37900",
    "CVE-2025-37954",
    "CVE-2025-38083",
    "CVE-2025-38373",
    "CVE-2025-38556",
    "CVE-2025-38591",
    "CVE-2025-38659",
    "CVE-2025-38730",
    "CVE-2025-39713",
    "CVE-2025-39961",
    "CVE-2025-40030",
    "CVE-2025-40096",
    "CVE-2025-40215",
    "CVE-2025-40220",
    "CVE-2025-40237",
    "CVE-2025-40242",
    "CVE-2025-40251",
    "CVE-2025-40271",
    "CVE-2025-40272",
    "CVE-2025-40277",
    "CVE-2025-40294",
    "CVE-2025-40301",
    "CVE-2025-40308",
    "CVE-2025-40318",
    "CVE-2025-40341",
    "CVE-2025-40342",
    "CVE-2025-40343",
    "CVE-2025-40346",
    "CVE-2025-40351",
    "CVE-2025-40358",
    "CVE-2025-40359",
    "CVE-2025-40361",
    "CVE-2025-68171",
    "CVE-2025-68173",
    "CVE-2025-68174",
    "CVE-2025-68176",
    "CVE-2025-68188",
    "CVE-2025-68200",
    "CVE-2025-68206",
    "CVE-2025-68208",
    "CVE-2025-68235",
    "CVE-2025-68259",
    "CVE-2025-68261",
    "CVE-2025-68264",
    "CVE-2025-68265",
    "CVE-2025-68297",
    "CVE-2025-68301",
    "CVE-2025-68309",
    "CVE-2025-68331",
    "CVE-2025-68337",
    "CVE-2025-68349",
    "CVE-2025-68354",
    "CVE-2025-68356",
    "CVE-2025-68362",
    "CVE-2025-68363",
    "CVE-2025-68376",
    "CVE-2025-68378",
    "CVE-2025-68724",
    "CVE-2025-68725",
    "CVE-2025-68734",
    "CVE-2025-68741",
    "CVE-2025-68744",
    "CVE-2025-68745",
    "CVE-2025-68756",
    "CVE-2025-68780",
    "CVE-2025-68782",
    "CVE-2025-68794",
    "CVE-2025-68803",
    "CVE-2025-68814",
    "CVE-2025-68816",
    "CVE-2025-68818",
    "CVE-2025-71072",
    "CVE-2025-71104",
    "CVE-2025-71116",
    "CVE-2025-71131",
    "CVE-2025-71147",
    "CVE-2025-71149",
    "CVE-2025-71150",
    "CVE-2026-22996",
    "CVE-2026-22998",
    "CVE-2026-23000",
    "CVE-2026-23005",
    "CVE-2026-23035",
    "CVE-2026-23138"
  ]
}