GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
oesa-2025-2272
Vulnerability from osv_openeuler
Published
2025-09-12 11:09
Modified
2026-08-06 11:09
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler. ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before.(CVE-2025-38119)

A NULL pointer dereference vulnerability exists in the Linux kernel's target subsystem. The function core_scsi3_decode_spec_i_port() unconditionally calls core_scsi3_lunacl_undepend_item() passing a potentially NULL dest_se_deve pointer in its error handling path, leading to kernel NULL pointer dereference. This vulnerability could be exploited to cause kernel crashes.(CVE-2025-38399)

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

bpf: Fix oob access in cgroup local storage

Lonial reported that an out-of-bounds access in cgroup local storage can be crafted via tail calls. Given two programs each utilizing a cgroup local storage with a different value size, and one program doing a tail call into the other. The verifier will validate each of the indivial programs just fine. However, in the runtime context the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the BPF program as well as any cgroup local storage flavor the program uses. Helpers such as bpf_get_local_storage() pick this up from the runtime context:

ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype];

if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf);

For the second program which was called from the originally attached one, this means bpf_get_local_storage() will pick up the former program's map, not its own. With mismatching sizes, this can result in an unintended out-of-bounds access.

To fix this issue, we need to extend bpf_map_owner with an array of storage_cookie[] to match on i) the exact maps from the original program if the second program was using bpf_get_local_storage(), or ii) allow the tail call combination if the second program was not using any of the cgroup local storage maps.(CVE-2025-38502)

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

net/mlx5: Check device memory pointer before usage

Add a NULL check before accessing device memory to prevent a crash if dev->dm allocation in mlx5_init_once() fails.(CVE-2025-38645)

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

ftrace: Also allocate and copy hash for reading of filter files

Currently the reader of set_ftrace_filter and set_ftrace_notrace just adds the pointer to the global tracer hash to its iterator. Unlike the writer that allocates a copy of the hash, the reader keeps the pointer to the filter hashes. This is problematic because this pointer is static across function calls that release the locks that can update the global tracer hashes. This can cause UAF and similar bugs.

Allocate and copy the hash for reading the filter files like it is done for the writers. This not only fixes UAF bugs, but also makes the code a bit simpler as it doesn't have to differentiate when to free the iterator's hash between writers and readers.(CVE-2025-39689)

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

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-281.0.0.183.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-281.0.0.183.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-281.0.0.183.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-281.0.0.183.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-281.0.0.183.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-281.0.0.183.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-281.0.0.183.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-281.0.0.183.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-281.0.0.183.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-281.0.0.183.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-281.0.0.183.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-281.0.0.183.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-281.0.0.183.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-281.0.0.183.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-281.0.0.183.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-281.0.0.183.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-281.0.0.183.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-281.0.0.183.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-281.0.0.183.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-281.0.0.183.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-281.0.0.183.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-281.0.0.183.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-281.0.0.183.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-281.0.0.183.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-281.0.0.183.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-281.0.0.183.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-281.0.0.183.oe2203sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-281.0.0.183.oe2203sp3"
            }
          ],
          "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: scsi: core: ufs: Fix a hang in the error handler. ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before.(CVE-2025-38119)\n\nA NULL pointer dereference vulnerability exists in the Linux kernel\u0026apos;s target subsystem. The function core_scsi3_decode_spec_i_port() unconditionally calls core_scsi3_lunacl_undepend_item() passing a potentially NULL dest_se_deve pointer in its error handling path, leading to kernel NULL pointer dereference. This vulnerability could be exploited to cause kernel crashes.(CVE-2025-38399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix oob access in cgroup local storage\n\nLonial reported that an out-of-bounds access in cgroup local storage\ncan be crafted via tail calls. Given two programs each utilizing a\ncgroup local storage with a different value size, and one program\ndoing a tail call into the other. The verifier will validate each of\nthe indivial programs just fine. However, in the runtime context\nthe bpf_cg_run_ctx holds an bpf_prog_array_item which contains the\nBPF program as well as any cgroup local storage flavor the program\nuses. Helpers such as bpf_get_local_storage() pick this up from the\nruntime context:\n\n  ctx = container_of(current-\u0026gt;bpf_ctx, struct bpf_cg_run_ctx, run_ctx);\n  storage = ctx-\u0026gt;prog_item-\u0026gt;cgroup_storage[stype];\n\n  if (stype == BPF_CGROUP_STORAGE_SHARED)\n    ptr = \u0026amp;READ_ONCE(storage-\u0026gt;buf)-\u0026gt;data[0];\n  else\n    ptr = this_cpu_ptr(storage-\u0026gt;percpu_buf);\n\nFor the second program which was called from the originally attached\none, this means bpf_get_local_storage() will pick up the former\nprogram\u0026apos;s map, not its own. With mismatching sizes, this can result\nin an unintended out-of-bounds access.\n\nTo fix this issue, we need to extend bpf_map_owner with an array of\nstorage_cookie[] to match on i) the exact maps from the original\nprogram if the second program was using bpf_get_local_storage(), or\nii) allow the tail call combination if the second program was not\nusing any of the cgroup local storage maps.(CVE-2025-38502)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Check device memory pointer before usage\n\nAdd a NULL check before accessing device memory to prevent a crash if\ndev-\u0026gt;dm allocation in mlx5_init_once() fails.(CVE-2025-38645)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Also allocate and copy hash for reading of filter files\n\nCurrently the reader of set_ftrace_filter and set_ftrace_notrace just adds\nthe pointer to the global tracer hash to its iterator. Unlike the writer\nthat allocates a copy of the hash, the reader keeps the pointer to the\nfilter hashes. This is problematic because this pointer is static across\nfunction calls that release the locks that can update the global tracer\nhashes. This can cause UAF and similar bugs.\n\nAllocate and copy the hash for reading the filter files like it is done\nfor the writers. This not only fixes UAF bugs, but also makes the code a\nbit simpler as it doesn\u0026apos;t have to differentiate when to free the\niterator\u0026apos;s hash between writers and readers.(CVE-2025-39689)",
  "id": "OESA-2025-2272",
  "modified": "2026-08-06T11:09:20Z",
  "published": "2025-09-12T11:09:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2272"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38119"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38399"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38502"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38645"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39689"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2025-38119",
    "CVE-2025-38399",
    "CVE-2025-38502",
    "CVE-2025-38645",
    "CVE-2025-39689"
  ]
}



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.