An update for kernel is now available for openEuler-22.03-LTS-SP3 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2025-2272 Final 1.0 1.0 2025-09-12 Initial 2025-09-12 2025-09-12 openEuler SA Tool V1.0 2025-09-12 kernel security update An update for kernel is now available for openEuler-22.03-LTS-SP3 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) An update for kernel is now available for openEuler-22.03-LTS-SP3. openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. High kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2272 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38119 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38399 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38502 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38645 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39689 https://nvd.nist.gov/vuln/detail/CVE-2025-38119 https://nvd.nist.gov/vuln/detail/CVE-2025-38399 https://nvd.nist.gov/vuln/detail/CVE-2025-38502 https://nvd.nist.gov/vuln/detail/CVE-2025-38645 https://nvd.nist.gov/vuln/detail/CVE-2025-39689 openEuler-22.03-LTS-SP3 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 kernel-5.10.0-281.0.0.183.oe2203sp3.src.rpm 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 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. 2025-09-12 CVE-2025-38119 openEuler-22.03-LTS-SP3 Low 3.9 AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L kernel security update 2025-09-12 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2272 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. 2025-09-12 CVE-2025-38399 openEuler-22.03-LTS-SP3 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-09-12 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2272 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. 2025-09-12 CVE-2025-38502 openEuler-22.03-LTS-SP3 Low 3.9 AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L kernel security update 2025-09-12 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2272 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. 2025-09-12 CVE-2025-38645 openEuler-22.03-LTS-SP3 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-09-12 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2272 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. 2025-09-12 CVE-2025-39689 openEuler-22.03-LTS-SP3 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-09-12 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2272