An update for kernel is now available for openEuler-22.03-LTS-SP4 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2025-2699 Final 1.0 1.0 2025-11-22 Initial 2025-11-22 2025-11-22 openEuler SA Tool V1.0 2025-11-22 kernel security update An update for kernel is now available for openEuler-22.03-LTS-SP4 The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved:ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_transThere is a kernel API ntb_mw_clear_trans() would pass 0 to both addr andsize. This would make xlate_pos negative.[ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000[ 23.734158] ================================================================================[ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7[ 23.734418] shift exponent -1 is negativeEnsuring xlate_pos is a positive or zero before BIT.(CVE-2023-53034) In the Linux kernel, the following vulnerability has been resolved:slimbus: messaging: Free transaction ID in delayed interrupt scenarioIn case of interrupt delay for any reason, slim_do_transfer()returns timeout error but the transaction ID (TID) is not freed.This results into invalid memory access insideqcom_slim_ngd_rx_msgq_cb() due to invalid TID.Fix the issue by freeing the TID in slim_do_transfer() beforereturning timeout error to avoid invalid memory access.Call trace:__memcpy_fromio+0x20/0x190qcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl]vchan_complete+0x2a0/0x4a0tasklet_action_common+0x274/0x700tasklet_action+0x28/0x3c_stext+0x188/0x620run_ksoftirqd+0x34/0x74smpboot_thread_fn+0x1d8/0x464kthread+0x178/0x238ret_from_fork+0x10/0x20Code: aa0003e8 91000429 f100044a 3940002b (3800150b)---[ end trace 0fe00bec2b975c99 ]---Kernel panic - not syncing: Oops: Fatal exception in interrupt.(CVE-2025-21914) In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: check that event count does not exceed event buffer length The event count is read from register DWC3_GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34(CVE-2025-37810) In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Validate UAC3 cluster segment descriptors UAC3 class segment descriptors need to be verified whether their sizes match with the declared lengths and whether they fit with the allocated buffer sizes, too. Otherwise malicious firmware may lead to the unexpected OOB accesses.(CVE-2025-39757) In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix crash in transport port remove by using ioc_info() During mpt3sas_transport_port_remove(), messages were logged with dev_printk() against &mpt3sas_port->port->dev. At this point the SAS transport device may already be partially unregistered or freed, leading to a crash when accessing its struct device. Using ioc_info(), which logs via the PCI device (ioc->pdev->dev), guaranteed to remain valid until driver removal. [83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI [83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G OE 6.16.0-rc1+ #1 PREEMPT(voluntary) [83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024 [83428.295799] RIP: 0010:__dev_printk+0x1f/0x70 [83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff [83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206 [83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32 [83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845 [83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8 [83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000 [83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30 [83428.295833] FS: 00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000 [83428.295837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0 [83428.295844] PKRU: 55555554 [83428.295846] Call Trace: [83428.295848] <TASK> [83428.295850] _dev_printk+0x5c/0x80 [83428.295857] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.295863] mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas] [83428.295882] _scsih_remove_device+0x21b/0x280 [mpt3sas] [83428.295894] ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas] [83428.295906] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.295910] mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas] [83428.295921] _scsih_expander_node_remove+0x129/0x140 [mpt3sas] [83428.295933] _scsih_expander_node_remove+0x6a/0x140 [mpt3sas] [83428.295944] scsih_remove+0x3f0/0x4a0 [mpt3sas] [83428.295957] pci_device_remove+0x3b/0xb0 [83428.295962] device_release_driver_internal+0x193/0x200 [83428.295968] driver_detach+0x44/0x90 [83428.295971] bus_remove_driver+0x69/0xf0 [83428.295975] pci_unregister_driver+0x2a/0xb0 [83428.295979] _mpt3sas_exit+0x1f/0x300 [mpt3sas] [83428.295991] __do_sys_delete_module.constprop.0+0x174/0x310 [83428.295997] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.296000] ? __x64_sys_getdents64+0x9a/0x110 [83428.296005] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.296009] ? syscall_trace_enter+0xf6/0x1b0 [83428.296014] do_syscall_64+0x7b/0x2c0 [83428.296019] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.296023] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-40115) In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce expected_attach_type for tailcall compatibility Yinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object. The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls. The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT. In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible(). Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and cpu_map_bpf_prog_run*() which set up a new environment / context and therefore these situations are not prone to this issue.(CVE-2025-40123) In the Linux kernel, the following vulnerability has been resolved: EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller When loading the i10nm_edac driver on some Intel Granite Rapids servers, a call trace may appear as follows: UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16 shift exponent -66 is negative ... __ubsan_handle_shift_out_of_bounds+0x1e3/0x390 skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common] i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac] skx_register_mci+0x159/0x220 [skx_edac_common] i10nm_init+0xcb0/0x1ff0 [i10nm_edac] ... This occurs because some BIOS may disable a memory controller if there aren't any memory DIMMs populated on this memory controller. The DIMMMTR register of this disabled memory controller contains the invalid value ~0, resulting in the call trace above. Fix this call trace by skipping DIMM enumeration on a disabled memory controller.(CVE-2025-40157) In the Linux kernel, the following vulnerability has been resolved: fs: quota: create dedicated workqueue for quota_release_work There is a kernel panic due to WARN_ONCE when panic_on_warn is set. This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance is needed at sync path, flush for quota_release_work is triggered. By default quota_release_work is queued to "events_unbound" queue which does not have WQ_MEM_RECLAIM flag. During f2fs balance "writeback" workqueue tries to flush quota_release_work causing kernel panic due to MEM_RECLAIM flag mismatch errors. This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag for work quota_release_work. ------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148 Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20 Kernel panic - not syncing: kernel: panic_on_warn set ...(CVE-2025-40196) An update for kernel is now available for openEuler-22.03-LTS-SP4. openEuler Security has rated this update as having a security impact of medium. 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. Medium kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2699 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-53034 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-21914 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-37810 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39757 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40115 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40123 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40157 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40196 https://nvd.nist.gov/vuln/detail/CVE-2023-53034 https://nvd.nist.gov/vuln/detail/CVE-2025-21914 https://nvd.nist.gov/vuln/detail/CVE-2025-37810 https://nvd.nist.gov/vuln/detail/CVE-2025-39757 https://nvd.nist.gov/vuln/detail/CVE-2025-40115 https://nvd.nist.gov/vuln/detail/CVE-2025-40123 https://nvd.nist.gov/vuln/detail/CVE-2025-40157 https://nvd.nist.gov/vuln/detail/CVE-2025-40196 openEuler-22.03-LTS-SP4 bpftool-5.10.0-291.0.0.194.oe2203sp4.aarch64.rpm bpftool-debuginfo-5.10.0-291.0.0.194.oe2203sp4.aarch64.rpm kernel-5.10.0-291.0.0.194.oe2203sp4.aarch64.rpm kernel-debuginfo-5.10.0-291.0.0.194.oe2203sp4.aarch64.rpm kernel-debugsource-5.10.0-291.0.0.194.oe2203sp4.aarch64.rpm kernel-devel-5.10.0-291.0.0.194.oe2203sp4.aarch64.rpm kernel-headers-5.10.0-291.0.0.194.oe2203sp4.aarch64.rpm kernel-source-5.10.0-291.0.0.194.oe2203sp4.aarch64.rpm kernel-tools-5.10.0-291.0.0.194.oe2203sp4.aarch64.rpm kernel-tools-debuginfo-5.10.0-291.0.0.194.oe2203sp4.aarch64.rpm kernel-tools-devel-5.10.0-291.0.0.194.oe2203sp4.aarch64.rpm perf-5.10.0-291.0.0.194.oe2203sp4.aarch64.rpm perf-debuginfo-5.10.0-291.0.0.194.oe2203sp4.aarch64.rpm python3-perf-5.10.0-291.0.0.194.oe2203sp4.aarch64.rpm python3-perf-debuginfo-5.10.0-291.0.0.194.oe2203sp4.aarch64.rpm bpftool-5.10.0-291.0.0.194.oe2203sp4.x86_64.rpm bpftool-debuginfo-5.10.0-291.0.0.194.oe2203sp4.x86_64.rpm kernel-5.10.0-291.0.0.194.oe2203sp4.x86_64.rpm kernel-debuginfo-5.10.0-291.0.0.194.oe2203sp4.x86_64.rpm kernel-debugsource-5.10.0-291.0.0.194.oe2203sp4.x86_64.rpm kernel-devel-5.10.0-291.0.0.194.oe2203sp4.x86_64.rpm kernel-headers-5.10.0-291.0.0.194.oe2203sp4.x86_64.rpm kernel-source-5.10.0-291.0.0.194.oe2203sp4.x86_64.rpm kernel-tools-5.10.0-291.0.0.194.oe2203sp4.x86_64.rpm kernel-tools-debuginfo-5.10.0-291.0.0.194.oe2203sp4.x86_64.rpm kernel-tools-devel-5.10.0-291.0.0.194.oe2203sp4.x86_64.rpm perf-5.10.0-291.0.0.194.oe2203sp4.x86_64.rpm perf-debuginfo-5.10.0-291.0.0.194.oe2203sp4.x86_64.rpm python3-perf-5.10.0-291.0.0.194.oe2203sp4.x86_64.rpm python3-perf-debuginfo-5.10.0-291.0.0.194.oe2203sp4.x86_64.rpm kernel-5.10.0-291.0.0.194.oe2203sp4.src.rpm In the Linux kernel, the following vulnerability has been resolved:ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_transThere is a kernel API ntb_mw_clear_trans() would pass 0 to both addr andsize. This would make xlate_pos negative.[ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000[ 23.734158] ================================================================================[ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7[ 23.734418] shift exponent -1 is negativeEnsuring xlate_pos is a positive or zero before BIT. 2025-11-22 CVE-2023-53034 openEuler-22.03-LTS-SP4 Low 3.9 AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L kernel security update 2025-11-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2699 In the Linux kernel, the following vulnerability has been resolved:slimbus: messaging: Free transaction ID in delayed interrupt scenarioIn case of interrupt delay for any reason, slim_do_transfer()returns timeout error but the transaction ID (TID) is not freed.This results into invalid memory access insideqcom_slim_ngd_rx_msgq_cb() due to invalid TID.Fix the issue by freeing the TID in slim_do_transfer() beforereturning timeout error to avoid invalid memory access.Call trace:__memcpy_fromio+0x20/0x190qcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl]vchan_complete+0x2a0/0x4a0tasklet_action_common+0x274/0x700tasklet_action+0x28/0x3c_stext+0x188/0x620run_ksoftirqd+0x34/0x74smpboot_thread_fn+0x1d8/0x464kthread+0x178/0x238ret_from_fork+0x10/0x20Code: aa0003e8 91000429 f100044a 3940002b (3800150b)---[ end trace 0fe00bec2b975c99 ]---Kernel panic - not syncing: Oops: Fatal exception in interrupt. 2025-11-22 CVE-2025-21914 openEuler-22.03-LTS-SP4 Low 3.9 AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L kernel security update 2025-11-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2699 In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: check that event count does not exceed event buffer length The event count is read from register DWC3_GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34 2025-11-22 CVE-2025-37810 openEuler-22.03-LTS-SP4 Low 3.9 AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L kernel security update 2025-11-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2699 In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Validate UAC3 cluster segment descriptors UAC3 class segment descriptors need to be verified whether their sizes match with the declared lengths and whether they fit with the allocated buffer sizes, too. Otherwise malicious firmware may lead to the unexpected OOB accesses. 2025-11-22 CVE-2025-39757 openEuler-22.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2699 In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix crash in transport port remove by using ioc_info() During mpt3sas_transport_port_remove(), messages were logged with dev_printk() against &mpt3sas_port->port->dev. At this point the SAS transport device may already be partially unregistered or freed, leading to a crash when accessing its struct device. Using ioc_info(), which logs via the PCI device (ioc->pdev->dev), guaranteed to remain valid until driver removal. [83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI [83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G OE 6.16.0-rc1+ #1 PREEMPT(voluntary) [83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024 [83428.295799] RIP: 0010:__dev_printk+0x1f/0x70 [83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff [83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206 [83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32 [83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845 [83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8 [83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000 [83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30 [83428.295833] FS: 00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000 [83428.295837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0 [83428.295844] PKRU: 55555554 [83428.295846] Call Trace: [83428.295848] <TASK> [83428.295850] _dev_printk+0x5c/0x80 [83428.295857] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.295863] mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas] [83428.295882] _scsih_remove_device+0x21b/0x280 [mpt3sas] [83428.295894] ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas] [83428.295906] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.295910] mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas] [83428.295921] _scsih_expander_node_remove+0x129/0x140 [mpt3sas] [83428.295933] _scsih_expander_node_remove+0x6a/0x140 [mpt3sas] [83428.295944] scsih_remove+0x3f0/0x4a0 [mpt3sas] [83428.295957] pci_device_remove+0x3b/0xb0 [83428.295962] device_release_driver_internal+0x193/0x200 [83428.295968] driver_detach+0x44/0x90 [83428.295971] bus_remove_driver+0x69/0xf0 [83428.295975] pci_unregister_driver+0x2a/0xb0 [83428.295979] _mpt3sas_exit+0x1f/0x300 [mpt3sas] [83428.295991] __do_sys_delete_module.constprop.0+0x174/0x310 [83428.295997] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.296000] ? __x64_sys_getdents64+0x9a/0x110 [83428.296005] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.296009] ? syscall_trace_enter+0xf6/0x1b0 [83428.296014] do_syscall_64+0x7b/0x2c0 [83428.296019] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.296023] entry_SYSCALL_64_after_hwframe+0x76/0x7e 2025-11-22 CVE-2025-40115 openEuler-22.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2699 In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce expected_attach_type for tailcall compatibility Yinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object. The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls. The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT. In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible(). Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and cpu_map_bpf_prog_run*() which set up a new environment / context and therefore these situations are not prone to this issue. 2025-11-22 CVE-2025-40123 openEuler-22.03-LTS-SP4 Medium 4.4 AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2699 In the Linux kernel, the following vulnerability has been resolved: EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller When loading the i10nm_edac driver on some Intel Granite Rapids servers, a call trace may appear as follows: UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16 shift exponent -66 is negative ... __ubsan_handle_shift_out_of_bounds+0x1e3/0x390 skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common] i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac] skx_register_mci+0x159/0x220 [skx_edac_common] i10nm_init+0xcb0/0x1ff0 [i10nm_edac] ... This occurs because some BIOS may disable a memory controller if there aren't any memory DIMMs populated on this memory controller. The DIMMMTR register of this disabled memory controller contains the invalid value ~0, resulting in the call trace above. Fix this call trace by skipping DIMM enumeration on a disabled memory controller. 2025-11-22 CVE-2025-40157 openEuler-22.03-LTS-SP4 Medium 4.4 AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2699 In the Linux kernel, the following vulnerability has been resolved: fs: quota: create dedicated workqueue for quota_release_work There is a kernel panic due to WARN_ONCE when panic_on_warn is set. This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance is needed at sync path, flush for quota_release_work is triggered. By default quota_release_work is queued to "events_unbound" queue which does not have WQ_MEM_RECLAIM flag. During f2fs balance "writeback" workqueue tries to flush quota_release_work causing kernel panic due to MEM_RECLAIM flag mismatch errors. This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag for work quota_release_work. ------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148 Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20 Kernel panic - not syncing: kernel: panic_on_warn set ... 2025-11-22 CVE-2025-40196 openEuler-22.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2699