{"schema_version":"1.7.2","id":"OESA-2026-1505","modified":"2026-03-06T12:41:35Z","published":"2026-03-06T12:41:35Z","upstream":["CVE-2023-53577","CVE-2023-53596","CVE-2025-71221","CVE-2026-23097","CVE-2026-23112","CVE-2026-23216"],"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\nbpf, cpumap: Make sure kthread is running before map update returns\n\nThe following warning was reported when running stress-mode enabled\nxdp_redirect_cpu with some RT threads:\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135\n  CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\n  Workqueue: events cpu_map_kthread_stop\n  RIP: 0010:put_cpu_map_entry+0xda/0x220\n  ......\n  Call Trace:\n   <TASK>\n   ? show_regs+0x65/0x70\n   ? __warn+0xa5/0x240\n   ......\n   ? put_cpu_map_entry+0xda/0x220\n   cpu_map_kthread_stop+0x41/0x60\n   process_one_work+0x6b0/0xb80\n   worker_thread+0x96/0x720\n   kthread+0x1a5/0x1f0\n   ret_from_fork+0x3a/0x70\n   ret_from_fork_asm+0x1b/0x30\n   </TASK>\n\nThe root cause is the same as commit 436901649731 ("bpf: cpumap: Fix memory\nleak in cpu_map_update_elem"). The kthread is stopped prematurely by\nkthread_stop() in cpu_map_kthread_stop(), and kthread() doesn't call\ncpu_map_kthread_run() at all but XDP program has already queued some\nframes or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checks\nthe ptr_ring, it will find it was not emptied and report a warning.\n\nAn alternative fix is to use __cpu_map_ring_cleanup() to drop these\npending frames or skbs when kthread_stop() returns -EINTR, but it may\nconfuse the user, because these frames or skbs have been handled\ncorrectly by XDP program. So instead of dropping these frames or skbs,\njust make sure the per-cpu kthread is running before\n__cpu_map_entry_alloc() returns.\n\nAfter apply the fix, the error handle for kthread_stop() will be\nunnecessary because it will always return 0, so just remove it.(CVE-2023-53577)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: base: Free devm resources when unregistering a device\n\nIn the current code, devres_release_all() only gets called if the device\nhas a bus and has been probed.\n\nThis leads to issues when using bus-less or driver-less devices where\nthe device might never get freed if a managed resource holds a reference\nto the device. This is happening in the DRM framework for example.\n\nWe should thus call devres_release_all() in the device_del() function to\nmake sure that the device-managed actions are properly executed when the\ndevice is unregistered, even if it has neither a bus nor a driver.\n\nThis is effectively the same change than commit 2f8d16a996da ("devres:\nrelease resources on device_del()") that got reverted by commit\na525a3ddeaca ("driver core: free devres in device_release") over\nmemory leaks concerns.\n\nThis patch effectively combines the two commits mentioned above to\nrelease the resources both on device_del() and device_release() and get\nthe best of both worlds.(CVE-2023-53596)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue()\n\nAdd proper locking in mmp_pdma_residue() to prevent use-after-free when\naccessing descriptor list and descriptor contents.\n\nThe race occurs when multiple threads call tx_status() while the tasklet\non another CPU is freeing completed descriptors:\n\nCPU 0                              CPU 1\n-----                              -----\nmmp_pdma_tx_status()\nmmp_pdma_residue()\n  -> NO LOCK held\n     list_for_each_entry(sw, ..)\n                                   DMA interrupt\n                                   dma_do_tasklet()\n                                     -> spin_lock(&desc_lock)\n                                        list_move(sw->node, ...)\n                                        spin_unlock(&desc_lock)\n  |                                     dma_pool_free(sw) <- FREED!\n  -> access sw->desc <- UAF!\n\nThis issue can be reproduced when running dmatest on the same channel with\nmultiple threads (threads_per_chan > 1).\n\nFix by protecting the chain_running list iteration and descriptor access\nwith the chan->desc_lock spinlock.(CVE-2025-71221)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmigrate: correct lock ordering for hugetlb file folios\n\nSyzbot has found a deadlock (analyzed by Lance Yang):\n\n1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock).\n2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire\nfolio_lock.\n\nmigrate_pages()\n  -> migrate_hugetlbs()\n    -> unmap_and_move_huge_page()     <- Takes folio_lock!\n      -> remove_migration_ptes()\n        -> __rmap_walk_file()\n          -> i_mmap_lock_read()       <- Waits for i_mmap_rwsem(read lock)!\n\nhugetlbfs_fallocate()\n  -> hugetlbfs_punch_hole()           <- Takes i_mmap_rwsem(write lock)!\n    -> hugetlbfs_zero_partial_page()\n     -> filemap_lock_hugetlb_folio()\n      -> filemap_lock_folio()\n        -> __filemap_get_folio        <- Waits for folio_lock!\n\nThe migration path is the one taking locks in the wrong order according to\nthe documentation at the top of mm/rmap.c.  So expand the scope of the\nexisting i_mmap_lock to cover the calls to remove_migration_ptes() too.\n\nThis is (mostly) how it used to be after commit c0d0381ade79.  That was\nremoved by 336bf30eb765 for both file & anon hugetlb pages when it should\nonly have been removed for anon hugetlb pages.(CVE-2026-23097)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec\n\nnvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU\nlength or offset exceeds sg_cnt and then use bogus sg->length/offset\nvalues, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining\nentries, and sg->length/offset before building the bvec.(CVE-2026-23112)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()\n\nIn iscsit_dec_conn_usage_count(), the function calls complete() while\nholding the conn->conn_usage_lock. As soon as complete() is invoked, the\nwaiter (such as iscsit_close_connection()) may wake up and proceed to free\nthe iscsit_conn structure.\n\nIf the waiter frees the memory before the current thread reaches\nspin_unlock_bh(), it results in a KASAN slab-use-after-free as the function\nattempts to release a lock within the already-freed connection structure.\n\nFix this by releasing the spinlock before calling complete().(CVE-2026-23216)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-303.0.0.206.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-303.0.0.206.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-303.0.0.206.oe2203sp4.aarch64.rpm","kernel-5.10.0-303.0.0.206.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-303.0.0.206.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-303.0.0.206.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-303.0.0.206.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-303.0.0.206.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-303.0.0.206.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-303.0.0.206.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-303.0.0.206.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-303.0.0.206.oe2203sp4.aarch64.rpm","perf-5.10.0-303.0.0.206.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-303.0.0.206.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-303.0.0.206.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-303.0.0.206.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-303.0.0.206.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-303.0.0.206.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-303.0.0.206.oe2203sp4.x86_64.rpm","kernel-5.10.0-303.0.0.206.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-303.0.0.206.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-303.0.0.206.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-303.0.0.206.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-303.0.0.206.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-303.0.0.206.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-303.0.0.206.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-303.0.0.206.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-303.0.0.206.oe2203sp4.x86_64.rpm","perf-5.10.0-303.0.0.206.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-303.0.0.206.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-303.0.0.206.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-303.0.0.206.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1505"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53577"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53596"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71221"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23097"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23112"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23216"}],"database_specific":{"severity":"High"}}