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-2535 Final 1.0 1.0 2025-10-24 Initial 2025-10-24 2025-10-24 openEuler SA Tool V1.0 2025-10-24 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: blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_none After grabbing q->sysfs_lock, q->elevator may become NULL because of elevator switch. Fix the NULL dereference on q->elevator by checking it with lock.(CVE-2023-53292) In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated In case of an ib_fast_reg_mr allocation failure during iSER setup, the machine hits a panic because iscsi_conn->dd_data is initialized unconditionally, even when no memory is allocated (dd_size == 0). This leads invalid pointer dereference during connection teardown. Fix by setting iscsi_conn->dd_data only if memory is actually allocated. Panic trace: ------------ iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70(CVE-2025-38700) In the Linux kernel, the following vulnerability has been resolved: loop: Avoid updating block size under exclusive owner Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in __getblk_slow() due to requested buffer size not matching block device block size. Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it.(CVE-2025-38709) In the Linux kernel, the following vulnerability has been resolved: NFS: Fix a race when updating an existing write After nfs_lock_and_join_requests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfs_inode_remove_request() from succeeding until we actually lock the page group. The reason is that whoever called nfs_inode_remove_request() doesn't necessarily have a lock on the page group head. So in order to avoid races, let's take the page group lock earlier in nfs_lock_and_join_requests(), and hold it across the removal of the request in nfs_inode_remove_request().(CVE-2025-39697) In the Linux kernel, the following vulnerability has been resolved: block: avoid possible overflow for chunk_sectors check in blk_stack_limits() In blk_stack_limits(), we check that the t->chunk_sectors value is a multiple of the t->physical_block_size value. However, by finding the chunk_sectors value in bytes, we may overflow the unsigned int which holds chunk_sectors, so change the check to be based on sectors.(CVE-2025-39795) 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 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-2535 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-53292 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38700 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38709 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39697 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39795 https://nvd.nist.gov/vuln/detail/CVE-2023-53292 https://nvd.nist.gov/vuln/detail/CVE-2025-38700 https://nvd.nist.gov/vuln/detail/CVE-2025-38709 https://nvd.nist.gov/vuln/detail/CVE-2025-39697 https://nvd.nist.gov/vuln/detail/CVE-2025-39795 openEuler-22.03-LTS-SP4 kernel-5.10.0-286.0.0.189.oe2203sp4.src.rpm bpftool-5.10.0-286.0.0.189.oe2203sp4.aarch64.rpm bpftool-debuginfo-5.10.0-286.0.0.189.oe2203sp4.aarch64.rpm kernel-5.10.0-286.0.0.189.oe2203sp4.aarch64.rpm kernel-debuginfo-5.10.0-286.0.0.189.oe2203sp4.aarch64.rpm kernel-debugsource-5.10.0-286.0.0.189.oe2203sp4.aarch64.rpm kernel-devel-5.10.0-286.0.0.189.oe2203sp4.aarch64.rpm kernel-headers-5.10.0-286.0.0.189.oe2203sp4.aarch64.rpm kernel-source-5.10.0-286.0.0.189.oe2203sp4.aarch64.rpm kernel-tools-5.10.0-286.0.0.189.oe2203sp4.aarch64.rpm kernel-tools-debuginfo-5.10.0-286.0.0.189.oe2203sp4.aarch64.rpm kernel-tools-devel-5.10.0-286.0.0.189.oe2203sp4.aarch64.rpm perf-5.10.0-286.0.0.189.oe2203sp4.aarch64.rpm perf-debuginfo-5.10.0-286.0.0.189.oe2203sp4.aarch64.rpm python3-perf-5.10.0-286.0.0.189.oe2203sp4.aarch64.rpm python3-perf-debuginfo-5.10.0-286.0.0.189.oe2203sp4.aarch64.rpm bpftool-5.10.0-286.0.0.189.oe2203sp4.x86_64.rpm bpftool-debuginfo-5.10.0-286.0.0.189.oe2203sp4.x86_64.rpm kernel-5.10.0-286.0.0.189.oe2203sp4.x86_64.rpm kernel-debuginfo-5.10.0-286.0.0.189.oe2203sp4.x86_64.rpm kernel-debugsource-5.10.0-286.0.0.189.oe2203sp4.x86_64.rpm kernel-devel-5.10.0-286.0.0.189.oe2203sp4.x86_64.rpm kernel-headers-5.10.0-286.0.0.189.oe2203sp4.x86_64.rpm kernel-source-5.10.0-286.0.0.189.oe2203sp4.x86_64.rpm kernel-tools-5.10.0-286.0.0.189.oe2203sp4.x86_64.rpm kernel-tools-debuginfo-5.10.0-286.0.0.189.oe2203sp4.x86_64.rpm kernel-tools-devel-5.10.0-286.0.0.189.oe2203sp4.x86_64.rpm perf-5.10.0-286.0.0.189.oe2203sp4.x86_64.rpm perf-debuginfo-5.10.0-286.0.0.189.oe2203sp4.x86_64.rpm python3-perf-5.10.0-286.0.0.189.oe2203sp4.x86_64.rpm python3-perf-debuginfo-5.10.0-286.0.0.189.oe2203sp4.x86_64.rpm In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_none After grabbing q->sysfs_lock, q->elevator may become NULL because of elevator switch. Fix the NULL dereference on q->elevator by checking it with lock. 2025-10-24 CVE-2023-53292 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-10-24 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2535 In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated In case of an ib_fast_reg_mr allocation failure during iSER setup, the machine hits a panic because iscsi_conn->dd_data is initialized unconditionally, even when no memory is allocated (dd_size == 0). This leads invalid pointer dereference during connection teardown. Fix by setting iscsi_conn->dd_data only if memory is actually allocated. Panic trace: ------------ iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70 2025-10-24 CVE-2025-38700 openEuler-22.03-LTS-SP4 Medium 5.3 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H kernel security update 2025-10-24 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2535 In the Linux kernel, the following vulnerability has been resolved: loop: Avoid updating block size under exclusive owner Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in __getblk_slow() due to requested buffer size not matching block device block size. Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it. 2025-10-24 CVE-2025-38709 openEuler-22.03-LTS-SP4 Medium 6.4 AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-10-24 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2535 In the Linux kernel, the following vulnerability has been resolved: NFS: Fix a race when updating an existing write After nfs_lock_and_join_requests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfs_inode_remove_request() from succeeding until we actually lock the page group. The reason is that whoever called nfs_inode_remove_request() doesn't necessarily have a lock on the page group head. So in order to avoid races, let's take the page group lock earlier in nfs_lock_and_join_requests(), and hold it across the removal of the request in nfs_inode_remove_request(). 2025-10-24 CVE-2025-39697 openEuler-22.03-LTS-SP4 High 7.5 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-10-24 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2535 In the Linux kernel, the following vulnerability has been resolved: block: avoid possible overflow for chunk_sectors check in blk_stack_limits() In blk_stack_limits(), we check that the t->chunk_sectors value is a multiple of the t->physical_block_size value. However, by finding the chunk_sectors value in bytes, we may overflow the unsigned int which holds chunk_sectors, so change the check to be based on sectors. 2025-10-24 CVE-2025-39795 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-10-24 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2535