{"schema_version":"1.7.2","id":"OESA-2025-2534","modified":"2025-10-24T14:34:01Z","published":"2025-10-24T14:34:01Z","upstream":["CVE-2023-53292","CVE-2023-53676","CVE-2025-38700","CVE-2025-38709","CVE-2025-39681","CVE-2025-39697","CVE-2025-39795"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_none\n\nAfter grabbing q->sysfs_lock, q->elevator may become NULL because of\nelevator switch.\n\nFix the NULL dereference on q->elevator by checking it with lock.(CVE-2023-53292)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the iSCSI component of the scsi target module. The function lio_target_nacl_info_show() uses sprintf() in a loop to print details for every iSCSI connection in a session without checking for the buffer length. With enough iSCSI connections it's possible to overflow the buffer provided by configfs and corrupt the memory. This patch replaces sprintf() with sysfs_emit_at() that checks for buffer boundaries.(CVE-2023-53676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated\n\nIn case of an ib_fast_reg_mr allocation failure during iSER setup, the\nmachine hits a panic because iscsi_conn->dd_data is initialized\nunconditionally, even when no memory is allocated (dd_size == 0).  This\nleads invalid pointer dereference during connection teardown.\n\nFix by setting iscsi_conn->dd_data only if memory is actually allocated.\n\nPanic trace:\n------------\n iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12\n iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers\n BUG: unable to handle page fault for address: fffffffffffffff8\n RIP: 0010:swake_up_locked.part.5+0xa/0x40\n Call Trace:\n  complete+0x31/0x40\n  iscsi_iser_conn_stop+0x88/0xb0 [ib_iser]\n  iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi]\n  iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi]\n  iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi]\n  ? netlink_lookup+0x12f/0x1b0\n  ? netlink_deliver_tap+0x2c/0x200\n  netlink_unicast+0x1ab/0x280\n  netlink_sendmsg+0x257/0x4f0\n  ? _copy_from_user+0x29/0x60\n  sock_sendmsg+0x5f/0x70(CVE-2025-38700)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nloop: Avoid updating block size under exclusive owner\n\nSyzbot came up with a reproducer where a loop device block size is\nchanged underneath a mounted filesystem. This causes a mismatch between\nthe block device block size and the block size stored in the superblock\ncausing confusion in various places such as fs/buffer.c. The particular\nissue triggered by syzbot was a warning in __getblk_slow() due to\nrequested buffer size not matching block device block size.\n\nFix the problem by getting exclusive hold of the loop device to change\nits block size. This fails if somebody (such as filesystem) has already\nan exclusive ownership of the block device and thus prevents modifying\nthe loop device under some exclusive owner which doesn't expect it.(CVE-2025-38709)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper\n\nSince\n\n  923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot")\n\nresctrl_cpu_detect() has been moved from common CPU initialization code to\nthe vendor-specific BSP init helper, while Hygon didn't put that call in their\ncode.\n\nThis triggers a division by zero fault during early booting stage on our\nmachines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() tries\nto calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale.\n\nAdd the missing resctrl_cpu_detect() in the Hygon BSP init helper.\n\n  [ bp: Massage commit message. ](CVE-2025-39681)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix a race when updating an existing write\n\nAfter nfs_lock_and_join_requests() tests for whether the request is\nstill attached to the mapping, nothing prevents a call to\nnfs_inode_remove_request() from succeeding until we actually lock the\npage group.\nThe reason is that whoever called nfs_inode_remove_request() doesn't\nnecessarily have a lock on the page group head.\n\nSo in order to avoid races, let's take the page group lock earlier in\nnfs_lock_and_join_requests(), and hold it across the removal of the\nrequest in nfs_inode_remove_request().(CVE-2025-39697)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock: avoid possible overflow for chunk_sectors check in blk_stack_limits()\n\nIn blk_stack_limits(), we check that the t->chunk_sectors value is a\nmultiple of the t->physical_block_size value.\n\nHowever, by finding the chunk_sectors value in bytes, we may overflow\nthe unsigned int which holds chunk_sectors, so change the check to be\nbased on sectors.(CVE-2025-39795)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP3","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-286.0.0.188.oe2203sp3"}]}],"ecosystem_specific":{"aarch64":["kernel-5.10.0-286.0.0.188.oe2203sp3.aarch64.rpm","kernel-debuginfo-5.10.0-286.0.0.188.oe2203sp3.aarch64.rpm","kernel-debugsource-5.10.0-286.0.0.188.oe2203sp3.aarch64.rpm","kernel-devel-5.10.0-286.0.0.188.oe2203sp3.aarch64.rpm","kernel-headers-5.10.0-286.0.0.188.oe2203sp3.aarch64.rpm","kernel-source-5.10.0-286.0.0.188.oe2203sp3.aarch64.rpm","kernel-tools-5.10.0-286.0.0.188.oe2203sp3.aarch64.rpm","kernel-tools-debuginfo-5.10.0-286.0.0.188.oe2203sp3.aarch64.rpm","kernel-tools-devel-5.10.0-286.0.0.188.oe2203sp3.aarch64.rpm","perf-5.10.0-286.0.0.188.oe2203sp3.aarch64.rpm","perf-debuginfo-5.10.0-286.0.0.188.oe2203sp3.aarch64.rpm","python3-perf-5.10.0-286.0.0.188.oe2203sp3.aarch64.rpm","python3-perf-debuginfo-5.10.0-286.0.0.188.oe2203sp3.aarch64.rpm"],"src":["kernel-5.10.0-286.0.0.188.oe2203sp3.src.rpm"],"x86_64":["kernel-5.10.0-286.0.0.188.oe2203sp3.x86_64.rpm","kernel-debuginfo-5.10.0-286.0.0.188.oe2203sp3.x86_64.rpm","kernel-debugsource-5.10.0-286.0.0.188.oe2203sp3.x86_64.rpm","kernel-devel-5.10.0-286.0.0.188.oe2203sp3.x86_64.rpm","kernel-headers-5.10.0-286.0.0.188.oe2203sp3.x86_64.rpm","kernel-source-5.10.0-286.0.0.188.oe2203sp3.x86_64.rpm","kernel-tools-5.10.0-286.0.0.188.oe2203sp3.x86_64.rpm","kernel-tools-debuginfo-5.10.0-286.0.0.188.oe2203sp3.x86_64.rpm","kernel-tools-devel-5.10.0-286.0.0.188.oe2203sp3.x86_64.rpm","perf-5.10.0-286.0.0.188.oe2203sp3.x86_64.rpm","perf-debuginfo-5.10.0-286.0.0.188.oe2203sp3.x86_64.rpm","python3-perf-5.10.0-286.0.0.188.oe2203sp3.x86_64.rpm","python3-perf-debuginfo-5.10.0-286.0.0.188.oe2203sp3.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2534"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53292"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53676"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38700"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38709"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39681"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39697"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39795"}],"database_specific":{"severity":"High"}}