GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

OESA-2026-3205 (CVE-2025-10263)

Vulnerability from osv_openeuler – Published: 2026-08-01 11:12 – Updated: 2026-08-06 11:12 – Source website
VLAI
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)

In the Linux kernel, the following vulnerability has been resolved:

ALSA: ac97: fix a double free in snd_ac97_controller_register()

If ac97_add_adapter() fails, put_device() is the correct way to drop the device reference. kfree() is not required. Add kfree() if idr_alloc() fails and in ac97_adapter_release() to do the cleanup.

Found by code review.(CVE-2025-71192)

In the Linux kernel, the following vulnerability has been resolved:

can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak

Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak").

In ems_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In ems_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted).

However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in ems_usb_close().

Fix the memory leak by anchoring the URB in the ems_usb_read_bulk_callback() to the dev->rx_submitted anchor.(CVE-2026-23058)

In the Linux kernel, the following vulnerability has been resolved:

locking/rtmutex: Skip remove_waiter() when waiter is not enqueued

syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI:

KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0

task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd ("rtmutex: Use waiter::task instead of current in remove_waiter()") made this fatal.

Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 ("futex: Handle early deadlock return correctly"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().(CVE-2026-53163)

In the Linux kernel, the following vulnerability has been resolved:

USB: serial: omninet: fix memory corruption with small endpoint

Make sure that the bulk-out buffers are at least as large as the hardcoded transfer size to avoid user-controlled slab corruption should a malicious device report a smaller endpoint max packet size than expected.(CVE-2026-63928)

In the Linux kernel, the following vulnerability has been resolved:

security/keys: fix missed RCU read section on lookup

Nicholas Carlini reports that the keyring code calls assoc_array_find() in find_key_to_update() without holding the RCU read lock, while the assoc_array_gc() code really is designed around removing the node from the tree and then freeing it after an RCU grace-period.

The regular key handling doesn't see this because holding the keyring semaphore hides any lifetime issues, but the persistent key handling uses a different model.

Instead of extending the keyring locking, just do the simple RCU locking that the assoc_array was designed for.(CVE-2026-64015)

In the Linux kernel, the following vulnerability has been resolved:

xfs: resample the data fork mapping after cycling ILOCK

xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared.

If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle.(CVE-2026-64600)

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
References
To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2607.4.0.0382.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2607.4.0.0382.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2607.4.0.0382.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nArm C1-Ultra, C1-Premium, Neoverse V3 \u0026amp; V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 \u0026amp; X1C, Cortex-A710, Cortex-A78, A78AE \u0026amp; A78C, Cortex-A77, Cortex-A76 \u0026amp; A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ac97: fix a double free in snd_ac97_controller_register()\n\nIf ac97_add_adapter() fails, put_device() is the correct way to drop\nthe device reference. kfree() is not required.\nAdd kfree() if idr_alloc() fails and in ac97_adapter_release() to do\nthe cleanup.\n\nFound by code review.(CVE-2025-71192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak\n\nFix similar memory leak as in commit 7352e1d5932a (\u0026quot;can: gs_usb:\ngs_usb_receive_bulk_callback(): fix URB memory leak\u0026quot;).\n\nIn ems_usb_open(), the URBs for USB-in transfers are allocated, added to\nthe dev-\u0026gt;rx_submitted anchor and submitted. In the complete callback\nems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In\nems_usb_close() the URBs are freed by calling\nusb_kill_anchored_urbs(\u0026amp;dev-\u0026gt;rx_submitted).\n\nHowever, this does not take into account that the USB framework unanchors\nthe URB before the complete function is called. This means that once an\nin-URB has been completed, it is no longer anchored and is ultimately not\nreleased in ems_usb_close().\n\nFix the memory leak by anchoring the URB in the\nems_usb_read_bulk_callback() to the dev-\u0026gt;rx_submitted anchor.(CVE-2026-23058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlocking/rtmutex: Skip remove_waiter() when waiter is not enqueued\n\nsyzbot triggered the following splat in remove_waiter() via\nFUTEX_CMP_REQUEUE_PI:\n\n  KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f]\n   class_raw_spinlock_constructor\n   remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561\n   rt_mutex_start_proxy_lock+0x103/0x120\n   futex_requeue+0x10e4/0x20d0\n   __x64_sys_futex+0x34f/0x4d0\n\ntask_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection,\nleaving waiter-\u0026gt;task nil, where 3bfdc63936dd (\u0026quot;rtmutex: Use waiter::task instead\nof current in remove_waiter()\u0026quot;) made this fatal.\n\nFurthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter()\nupon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\u0026quot;futex: Handle early deadlock\nreturn correctly\u0026quot;), moved the remove_waiter() out of __rt_mutex_start_proxy_lock()\n(where \u0026apos;ret\u0026apos; was only ever 0 or \u0026lt; 0) into the wrapper. Tighten this check to\naccount for try_to_take_rt_mutex().(CVE-2026-53163)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: omninet: fix memory corruption with small endpoint\n\nMake sure that the bulk-out buffers are at least as large as the\nhardcoded transfer size to avoid user-controlled slab corruption should\na malicious device report a smaller endpoint max packet size than\nexpected.(CVE-2026-63928)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsecurity/keys: fix missed RCU read section on lookup\n\nNicholas Carlini reports that the keyring code calls assoc_array_find()\nin find_key_to_update() without holding the RCU read lock, while the\nassoc_array_gc() code really is designed around removing the node from\nthe tree and then freeing it after an RCU grace-period.\n\nThe regular key handling doesn\u0026apos;t see this because holding the keyring\nsemaphore hides any lifetime issues, but the persistent key handling\nuses a different model.\n\nInstead of extending the keyring locking, just do the simple RCU locking\nthat the assoc_array was designed for.(CVE-2026-64015)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: resample the data fork mapping after cycling ILOCK\n\nxfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode,\na data fork mapping, and a cow fork mapping.  Unfortunately, these two\nhelpers cycle the ILOCK to grab a transaction, which means that the\nmappings are stale as soon as we reacquire the ILOCK.  Currently we\nrefresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but\nwe don\u0026apos;t refresh the data fork mapping beforehand, which means that the\nxfs_bmap_trim_cow in that function queries the refcount btree about the\nwrong physical blocks and returns an inaccurate value in *shared.\n\nIf *shared is now false, the directio write proceeds with a stale data\nfork mapping.  Fix this by querying the data fork mapping if the\nsequence counter changes across the ILOCK cycle.(CVE-2026-64600)",
  "id": "OESA-2026-3205",
  "modified": "2026-08-06T11:12:04Z",
  "published": "2026-08-01T11:12:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3205"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10263"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71192"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23058"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53163"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63928"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64015"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64600"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2025-10263",
    "CVE-2025-71192",
    "CVE-2026-23058",
    "CVE-2026-53163",
    "CVE-2026-63928",
    "CVE-2026-64015",
    "CVE-2026-64600"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.