OESA-2025-1247

Source
https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2025-1247
Import Source
https://repo.openeuler.org/security/data/osv/OESA-2025-1247.json
JSON Data
https://api.osv.dev/v1/vulns/OESA-2025-1247
Upstream
Published
2025-03-07T11:08:20Z
Modified
2026-08-18T01:17:49Z
Severity
  • 7.8 (High) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H CVSS Calculator
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:

af_packet: avoid erroring out after sock_init_data() in packet_create()

After sock_init_data() the allocated sk object is attached to the provided sock object. On error, packet_create() frees the sk object leaving the dangling pointer in the sock object on return. Some other code may try to use this pointer and cause use-after-free.(CVE-2024-56606)

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

iio: imu: kmx61: fix information leak in triggered buffer

The 'buffer' local array is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values.

Initialize the array to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57908)

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

iio: pressure: zpa2326: fix information leak in triggered buffer

The 'sample' local struct is used to push data to user space from a triggered buffer, but it has a hole between the temperature and the timestamp (u32 pressure, u16 temperature, GAP, u64 timestamp). This hole is never initialized.

Initialize the struct to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57912)

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

memcg: fix soft lockup in the OOM process

A soft lockup issue was found in the product with about 56,000 tasks were in the OOM cgroup, it was traversing them when the soft lockup was triggered.

watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066] CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G Hardware name: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:console_unlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vprintk_emit+0x193/0x280 printk+0x52/0x6e dump_task+0x114/0x130 mem_cgroup_scan_tasks+0x76/0x100 dump_header+0x1fe/0x210 oom_kill_process+0xd1/0x100 out_of_memory+0x125/0x570 mem_cgroup_out_of_memory+0xb5/0xd0 try_charge+0x720/0x770 mem_cgroup_try_charge+0x86/0x180 mem_cgroup_try_charge_delay+0x1c/0x40 do_anonymous_page+0xb5/0x390 handle_mm_fault+0xc4/0x1f0

This is because thousands of processes are in the OOM cgroup, it takes a long time to traverse all of them. As a result, this lead to soft lockup in the OOM process.

To fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks' function per 1000 iterations. For global OOM, call 'touch_softlockup_watchdog' per 1000 iterations to avoid this issue.(CVE-2024-57977)

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

net: hns3: fixed hclge_fetch_pf_reg accesses bar space out of bounds issue

The TQP BAR space is divided into two segments. TQPs 0-1023 and TQPs 1024-1279 are in different BAR space addresses. However, hclge_fetch_pf_reg does not distinguish the tqp space information when reading the tqp space information. When the number of TQPs is greater than 1024, access bar space overwriting occurs. The problem of different segments has been considered during the initialization of tqp.io_base. Therefore, tqp.io_base is directly used when the queue is read in hclge_fetch_pf_reg.

The error message:

Unable to handle kernel paging request at virtual address ffff800037200000 pc : hclge_fetch_pf_reg+0x138/0x250 [hclge] lr : hclge_get_regs+0x84/0x1d0 [hclge] Call trace: hclge_fetch_pf_reg+0x138/0x250 [hclge] hclge_get_regs+0x84/0x1d0 [hclge] hns3_get_regs+0x2c/0x50 [hns3] ethtool_get_regs+0xf4/0x270 dev_ethtool+0x674/0x8a0 dev_ioctl+0x270/0x36c sock_do_ioctl+0x110/0x2a0 sock_ioctl+0x2ac/0x530 __arm64_sys_ioctl+0xa8/0x100 invoke_syscall+0x4c/0x124 el0_svc_common.constprop.0+0x140/0x15c do_el0_svc+0x30/0xd0 el0_svc+0x1c/0x2c el0_sync_handler+0xb0/0xb4 el0_sync+0x168/0x180(CVE-2025-21650)

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

net: hns3: don't auto enable misc vector

Currently, there is a time window between misc irq enabled and service task inited. If an interrupte is reported at this time, it will cause warning like below:

[ 16.324639] Call trace: [ 16.324641] __queue_delayed_work+0xb8/0xe0 [ 16.324643] mod_delayed_work_on+0x78/0xd0 [ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge] [ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge] [ 16.324666] __handle_irq_event_percpu+0x64/0x1e0 [ 16.324667] handle_irq_event+0x80/0x170 [ 16.324670] handle_fasteoi_edge_irq+0x110/0x2bc [ 16.324671] __handle_domain_irq+0x84/0xfc [ 16.324673] gic_handle_irq+0x88/0x2c0 [ 16.324674] el1_irq+0xb8/0x140 [ 16.324677] arch_cpu_idle+0x18/0x40 [ 16.324679] default_idle_call+0x5c/0x1bc [ 16.324682] cpuidle_idle_call+0x18c/0x1c4 [ 16.324684] do_idle+0x174/0x17c [ 16.324685] cpu_startup_entry+0x30/0x6c [ 16.324687] secondary_start_kernel+0x1a4/0x280 [ 16.324688] ---[ end trace 6aa0bff672a964aa ]---

So don't auto enable misc vector when request irq..(CVE-2025-21651)

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

nbd: don't allow reconnect after disconnect

Following process can cause nbd_config UAF:

  1. grab nbd_config temporarily;

  2. nbd_genl_disconnect() flush all recv_work() and release the initial reference:

nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero

  1. nbd_genl_reconfigure() queue recv_work() again;

nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work)

  1. step 1) release the reference;

  2. Finially, recv_work() will trigger UAF:

recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAF

Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so that nbd_genl_reconfigure() will fail.(CVE-2025-21731)

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

mm/compaction: fix UBSAN shift-out-of-bounds warning

syzkaller reported a UBSAN shift-out-of-bounds warning of (1UL << order) in isolate_freepages_block(). The bogus compound_order can be any value because it is union with flags. Add back the MAX_PAGE_ORDER check to fix the warning.(CVE-2025-21815)

Database specific
{
    "severity": "High"
}
References

Affected packages

openEuler:22.03-LTS-SP4 / kernel

Package

Name
kernel
Purl
pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0 Unknown introduced version / All previous versions are affected
Fixed
5.10.0-252.0.0.156.oe2203sp4

Ecosystem specific

{
    "aarch64": [
        "bpftool-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm",
        "bpftool-debuginfo-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm",
        "kernel-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm",
        "kernel-debuginfo-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm",
        "kernel-debugsource-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm",
        "kernel-devel-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm",
        "kernel-headers-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm",
        "kernel-source-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm",
        "kernel-tools-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm",
        "kernel-tools-debuginfo-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm",
        "kernel-tools-devel-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm",
        "perf-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm",
        "perf-debuginfo-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm",
        "python3-perf-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm",
        "python3-perf-debuginfo-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm"
    ],
    "src": [
        "kernel-5.10.0-252.0.0.156.oe2203sp4.src.rpm"
    ],
    "x86_64": [
        "bpftool-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm",
        "bpftool-debuginfo-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm",
        "kernel-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm",
        "kernel-debuginfo-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm",
        "kernel-debugsource-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm",
        "kernel-devel-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm",
        "kernel-headers-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm",
        "kernel-source-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm",
        "kernel-tools-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm",
        "kernel-tools-debuginfo-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm",
        "kernel-tools-devel-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm",
        "perf-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm",
        "perf-debuginfo-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm",
        "python3-perf-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm",
        "python3-perf-debuginfo-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm"
    ]
}

Database specific

source
"https://repo.openeuler.org/security/data/osv/OESA-2025-1247.json"