An update for kernel is now available for openEuler-24.03-LTS-SP1 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2026-4437 Final 1.0 1.0 2026-10-22 Initial 2026-10-22 2026-10-22 openEuler SA Tool V1.0 2026-10-22 kernel security update An update for kernel is now available for openEuler-24.03-LTS-SP1 The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode Currently, whenever there is a need to transmit an Action frame, the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to firmware. The P2P interfaces were available when wpa_supplicant is managing the wlan interface. However, the P2P interfaces are not created/initialized when only hostapd is managing the wlan interface. And if hostapd receives an ANQP Query REQ Action frame even from an un-associated STA, the brcmfmac driver tries to use an uninitialized P2P vif pointer for sending the IOVAR to firmware. This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000) Fix this, by always using the vif corresponding to the wdev on which the Action frame Transmission request was initiated by the userspace. This way, even if P2P vif is not available, the IOVAR is sent to firmware on AP vif and the ANQP Query RESP Action frame is transmitted without crashing the driver. Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev() to brcmf_p2p_attach(). Because the former function would not get executed when only hostapd is managing wlan interface, and it is not safe to do reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior init_completion(). And in the brcmf_p2p_tx_action_frame() function, the condition check for P2P Presence response frame is not needed, since the wpa_supplicant is properly sending the P2P Presense Response frame on the P2P-GO vif instead of the P2P-Device vif. [Cc stable](CVE-2025-40321) In the Linux kernel, the following vulnerability has been resolved: ASoC: topology: Check PCM and DAI name strings before use Topology objects store several PCM and DAI names in fixed-size UAPI arrays. Other topology parser paths validate these fields with bounded strnlen() checks before using them as C strings, but the PCM and DAI paths still pass some fixed-size arrays directly to strlen(), devm_kstrdup(), DAI lookup, and diagnostic prints. A malformed topology blob with a non-NUL-terminated PCM, DAI, or stream capability name can therefore make the parser read past the end of the fixed-size field. Reject unterminated PCM and DAI name fields before consuming them as C strings.(CVE-2026-74291) In the Linux kernel, the following vulnerability has been resolved: xfs: fix ilock leak on error in xfs_dq_get_next_id xfs_dq_get_next_id() takes the quota inode ILOCK before calling xfs_iread_extents(). If xfs_iread_extents() fails, the function returns immediately without releasing the lock, leaking the quota inode ILOCK. This can leave the quota inode locked and cause subsequent quota operations to hang. Fix this by jumping to a common unlock path on error instead of returning directly.(CVE-2026-80534) In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix double free of wq, engine, and group structs The release callbacks for wq, engine, and group devices (idxd_conf_wq_release, idxd_conf_engine_release, idxd_conf_group_release) each call kfree() on the enclosing struct. The setup error paths and cleanup functions also call kfree() explicitly after put_device(), producing a double free whenever put_device() drops the reference count to zero and fires the release. In the setup functions, device_initialize() is called before device_add(), so the reference count is exactly 1 at the error sites. put_device() unconditionally fires the release, which frees the struct; the subsequent explicit kfree() then operates on freed memory. For idxd_setup_wqs(), the wq release callback also owns opcap_bmap and wqcfg. The error unwind additionally freed those fields explicitly before calling put_device(), causing further double frees on both. Remove the redundant explicit kfree() calls from all setup error paths and cleanup functions for wq, engine, and group structs, delegating sole ownership of those allocations to the release callbacks.(CVE-2026-80698) An update for kernel is now available for openEuler-24.03-LTS-SP3/openEuler-24.03-LTS-SP4/openEuler-24.03-LTS/openEuler-24.03-LTS-SP1/openEuler-22.03-LTS-SP3/openEuler-24.03-LTS-SP2. 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-2026-4437 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40321 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-74291 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-80534 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-80698 https://nvd.nist.gov/vuln/detail/CVE-2025-40321 https://nvd.nist.gov/vuln/detail/CVE-2026-74291 https://nvd.nist.gov/vuln/detail/CVE-2026-80534 https://nvd.nist.gov/vuln/detail/CVE-2026-80698 openEuler-24.03-LTS-SP1 bpftool-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm bpftool-debuginfo-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm kernel-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm kernel-debuginfo-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm kernel-debugsource-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm kernel-devel-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm kernel-headers-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm kernel-source-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm kernel-tools-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm kernel-tools-debuginfo-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm kernel-tools-devel-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm perf-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm perf-debuginfo-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm python3-perf-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm python3-perf-debuginfo-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm bpftool-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm bpftool-debuginfo-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm kernel-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm kernel-debuginfo-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm kernel-debugsource-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm kernel-devel-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm kernel-headers-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm kernel-source-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm kernel-tools-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm kernel-tools-debuginfo-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm kernel-tools-devel-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm perf-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm perf-debuginfo-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm python3-perf-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm python3-perf-debuginfo-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm kernel-6.6.0-145.1.28.165.oe2403sp1.src.rpm In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode Currently, whenever there is a need to transmit an Action frame, the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to firmware. The P2P interfaces were available when wpa_supplicant is managing the wlan interface. However, the P2P interfaces are not created/initialized when only hostapd is managing the wlan interface. And if hostapd receives an ANQP Query REQ Action frame even from an un-associated STA, the brcmfmac driver tries to use an uninitialized P2P vif pointer for sending the IOVAR to firmware. This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000) Fix this, by always using the vif corresponding to the wdev on which the Action frame Transmission request was initiated by the userspace. This way, even if P2P vif is not available, the IOVAR is sent to firmware on AP vif and the ANQP Query RESP Action frame is transmitted without crashing the driver. Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev() to brcmf_p2p_attach(). Because the former function would not get executed when only hostapd is managing wlan interface, and it is not safe to do reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior init_completion(). And in the brcmf_p2p_tx_action_frame() function, the condition check for P2P Presence response frame is not needed, since the wpa_supplicant is properly sending the P2P Presense Response frame on the P2P-GO vif instead of the P2P-Device vif. [Cc stable] 2026-10-22 CVE-2025-40321 openEuler-24.03-LTS-SP1 Medium 6.4 AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H kernel security update 2026-10-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4437 In the Linux kernel, the following vulnerability has been resolved: ASoC: topology: Check PCM and DAI name strings before use Topology objects store several PCM and DAI names in fixed-size UAPI arrays. Other topology parser paths validate these fields with bounded strnlen() checks before using them as C strings, but the PCM and DAI paths still pass some fixed-size arrays directly to strlen(), devm_kstrdup(), DAI lookup, and diagnostic prints. A malformed topology blob with a non-NUL-terminated PCM, DAI, or stream capability name can therefore make the parser read past the end of the fixed-size field. Reject unterminated PCM and DAI name fields before consuming them as C strings. 2026-10-22 CVE-2026-74291 openEuler-24.03-LTS-SP1 Medium 6.0 AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H kernel security update 2026-10-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4437 In the Linux kernel, the following vulnerability has been resolved: xfs: fix ilock leak on error in xfs_dq_get_next_id xfs_dq_get_next_id() takes the quota inode ILOCK before calling xfs_iread_extents(). If xfs_iread_extents() fails, the function returns immediately without releasing the lock, leaking the quota inode ILOCK. This can leave the quota inode locked and cause subsequent quota operations to hang. Fix this by jumping to a common unlock path on error instead of returning directly. 2026-10-22 CVE-2026-80534 openEuler-24.03-LTS-SP1 Medium 4.7 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2026-10-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4437 In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix double free of wq, engine, and group structs The release callbacks for wq, engine, and group devices (idxd_conf_wq_release, idxd_conf_engine_release, idxd_conf_group_release) each call kfree() on the enclosing struct. The setup error paths and cleanup functions also call kfree() explicitly after put_device(), producing a double free whenever put_device() drops the reference count to zero and fires the release. In the setup functions, device_initialize() is called before device_add(), so the reference count is exactly 1 at the error sites. put_device() unconditionally fires the release, which frees the struct; the subsequent explicit kfree() then operates on freed memory. For idxd_setup_wqs(), the wq release callback also owns opcap_bmap and wqcfg. The error unwind additionally freed those fields explicitly before calling put_device(), causing further double frees on both. Remove the redundant explicit kfree() calls from all setup error paths and cleanup functions for wq, engine, and group structs, delegating sole ownership of those allocations to the release callbacks. 2026-10-22 CVE-2026-80698 openEuler-24.03-LTS-SP1 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2026-10-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4437