- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] RDMA/umem: Fix truncation for block sizes >= 4G
by Xia Fukun 01 Jul '26

01 Jul '26

From: Jason Gunthorpe <jgg(a)nvidia.com> mainline inclusion from mainline-v7.1 commit 15fe76e23615f502d051ef0768f86babaf08746c category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15827 CVE: CVE-2026-53133 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses. Link: https://patch.msgid.link/r/1-v1-88303e9e509f+f7-ib_umem_types_jgg@nvidia.com Cc: stable(a)vger.kernel.org Fixes: a808273a495c ("RDMA/verbs: Add a DMA iterator to return aligned contiguous memory blocks") Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> Conflicts: drivers/infiniband/core/iter.c drivers/infiniband/core/verbs.c [Newer versions moved this function to iter.c, this version adapts the changes in verbs.c.] Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/infiniband/core/verbs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c index 47a969a7f6f6..1b87b8d02cf9 100644 --- a/drivers/infiniband/core/verbs.c +++ b/drivers/infiniband/core/verbs.c @@ -2644,7 +2644,7 @@ EXPORT_SYMBOL(__rdma_block_iter_start); bool __rdma_block_iter_next(struct ib_block_iter *biter) { - unsigned int block_offset; + dma_addr_t block_offset; if (!biter->__sg_nents || !biter->__sg) return false; -- 2.34.1

2 1

[patch OLK-6.6] cgroup/psi: Set of->priv to NULL upon file release
by Cai Xinchen 01 Jul '26

01 Jul '26

From: Chen Ridong <chenridong(a)huawei.com> mainline inclusion from mainline-v6.17-rc7 commit 94a4acfec14615e971eb2c9e1fa6c992c85ff6c6 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15693 CVE: CVE-2026-52991 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Setting of->priv to NULL when the file is released enables earlier bug detection. This allows potential bugs to manifest as NULL pointer dereferences rather than use-after-free errors[1], which are generally more difficult to diagnose. [1] https://lore.kernel.org/cgroups/38ef3ff9-b380-44f0-9315-8b3714b0948d@huawei… Signed-off-by: Chen Ridong <chenridong(a)huawei.com> Signed-off-by: Tejun Heo <tj(a)kernel.org> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- kernel/cgroup/cgroup.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c index 6949584610a5..7e08f494c61c 100644 --- a/kernel/cgroup/cgroup.c +++ b/kernel/cgroup/cgroup.c @@ -4215,6 +4215,7 @@ static void cgroup_file_release(struct kernfs_open_file *of) cft->release(of); put_cgroup_ns(ctx->ns); kfree(ctx); + of->priv = NULL; } static ssize_t cgroup_file_write(struct kernfs_open_file *of, char *buf, -- 2.18.0.huawei.25

1 0

[PATCH openEuler-1.0-LTS] IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN
by Xia Fukun 01 Jul '26

01 Jul '26

From: Michael Bommarito <michael.bommarito(a)gmail.com> mainline inclusion from mainline-v7.1 commit 29e7b925ae6df64894e82ab6419994dc25580a8a category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15861 CVE: CVE-2026-53176 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added. Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Link: https://patch.msgid.link/r/20260602194642.2273217-1-michael.bommarito@gmail… Cc: stable(a)vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito <michael.bommarito(a)gmail.com> Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> Conflicts: drivers/infiniband/ulp/isert/ib_isert.c [Context differences, unrelated to the fix patch.] Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/infiniband/ulp/isert/ib_isert.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/infiniband/ulp/isert/ib_isert.c b/drivers/infiniband/ulp/isert/ib_isert.c index f39670c5c25c..97119e8e0751 100644 --- a/drivers/infiniband/ulp/isert/ib_isert.c +++ b/drivers/infiniband/ulp/isert/ib_isert.c @@ -1473,6 +1473,12 @@ isert_login_recv_done(struct ib_cq *cq, struct ib_wc *wc) ib_dma_sync_single_for_cpu(ib_dev, isert_conn->login_req_dma, ISER_RX_PAYLOAD_SIZE, DMA_FROM_DEVICE); + if (unlikely(wc->byte_len < ISER_HEADERS_LEN)) { + isert_dbg("login request length %u is too short\n", + wc->byte_len); + return; + } + isert_conn->login_req_len = wc->byte_len - ISER_HEADERS_LEN; if (isert_conn->conn) { -- 2.34.1

2 1

[PATCH OLK-6.6] ipc/shm: serialize orphan cleanup with shm_nattch updates
by Fanhua Li 01 Jul '26

01 Jul '26

From: Yilin Zhu <zylzyl2333(a)gmail.com> stable inclusion from stable-v5.10.259 commit b1e9aef48e4d8a0c1b54fb913077b0824ed7d650 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15634 CVE: CVE-2026-52930 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 2e5c6f4fd4001562781e99bbfc7f1f0127187542 upstream. shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal. Link: https://lore.kernel.org/9d97cc1031de2d0bace0edf3a668818aa2f4eca6.1777410234… Fixes: 4c677e2eefdb ("shm: optimize locking and ipc_namespace getting") Reported-by: Yuan Tan <yuantan098(a)gmail.com> Reported-by: Yifan Wu <yifanwucs(a)gmail.com> Reported-by: Juefei Pu <tomapufckgml(a)gmail.com> Reported-by: Xin Liu <bird(a)lzu.edu.cn> Signed-off-by: Yilin Zhu <zylzyl2333(a)gmail.com> Signed-off-by: Ren Wei <n05ec(a)lzu.edu.cn> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Jeongjun Park <aha310510(a)gmail.com> Cc: Kees Cook <kees(a)kernel.org> Cc: Liam Howlett <liam(a)infradead.org> Cc: Lorenzo Stoakes <ljs(a)kernel.org> Cc: Serge Hallyn <sergeh(a)kernel.org> Cc: Vasiliy Kulikov <segoon(a)openwall.com> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: Serge Hallyn <serge(a)hallyn.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Fanhua Li <lifanhua5(a)huawei.com> --- ipc/shm.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/ipc/shm.c b/ipc/shm.c index bb017dd760f4d..25190965c9a50 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -415,15 +415,17 @@ static int shm_try_destroy_orphaned(int id, void *p, void *data) * We want to destroy segments without users and with already * exit'ed originating process. * - * As shp->* are changed under rwsem, it's safe to skip shp locking. + * shm_nattch can be changed under shm_perm.lock without holding the + * rwsem, so take the object lock before checking shm_may_destroy(). */ if (!list_empty(&shp->shm_clist)) return 0; - if (shm_may_destroy(shp)) { - shm_lock_by_ptr(shp); + shm_lock_by_ptr(shp); + if (shm_may_destroy(shp)) shm_destroy(ns, shp); - } + else + shm_unlock(shp); return 0; } -- 2.43.0

2 1

[PATCH openEuler-1.0-LTS] USB: serial: kl5kusb105: fix bulk-out buffer overflow
by Jinjie Ruan 01 Jul '26

01 Jul '26

From: HyeongJun An <sammiee5311(a)gmail.com> stable inclusion from stable-v6.6.143 commit a1288cd700f721c1a119c4f1e8efa234e59caada category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15880 CVE: CVE-2026-53194 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 96d47e40bf9db4a9efd5c8fb53287a508d165f14 upstream. klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied. Fixes: 60b3013cdaf3 ("USB: kl5usb105: reimplement using generic framework") Cc: stable(a)vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An <sammiee5311(a)gmail.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- drivers/usb/serial/kl5kusb105.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/kl5kusb105.c b/drivers/usb/serial/kl5kusb105.c index 5ee48b0650c4..472043568d6a 100644 --- a/drivers/usb/serial/kl5kusb105.c +++ b/drivers/usb/serial/kl5kusb105.c @@ -361,8 +361,8 @@ static int klsi_105_prepare_write_buffer(struct usb_serial_port *port, unsigned char *buf = dest; int count; - count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, - &port->lock); + count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, + size - KLSI_HDR_LEN, &port->lock); put_unaligned_le16(count, buf); return count + KLSI_HDR_LEN; -- 2.34.1

2 1

[PATCH OLK-6.6] ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size
by Pan Taixi 01 Jul '26

01 Jul '26

From: Viacheslav Dubeyko <Slava.Dubeyko(a)ibm.com> mainline inclusion from mainline-v7.1-rc4 commit 0c22d9511cbde746622f8e4c11aaa63fe76d45f9 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15663 CVE: CVE-2026-52961 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The generic/642 test-case can reproduce the kernel crash: [40243.605254] ------------[ cut here ]------------ [40243.605956] kernel BUG at fs/ceph/xattr.c:918! [40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI [40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full) [40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [40243.611820] Workqueue: ceph-msgr ceph_con_workfn [40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0 [40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc [40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287 [40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000 [40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000 [40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000 [40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000 [40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd [40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000 [40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0 [40243.627408] Call Trace: [40243.627839] <TASK> [40243.628188] __prep_cap+0x3fd/0x4a0 [40243.628789] ? do_raw_spin_unlock+0x4e/0xe0 [40243.629474] ceph_check_caps+0x46a/0xc80 [40243.630094] ? __lock_acquire+0x4a2/0x2650 [40243.630773] ? find_held_lock+0x31/0x90 [40243.631347] ? handle_cap_grant+0x79f/0x1060 [40243.632068] ? lock_release+0xd9/0x300 [40243.632696] ? __mutex_unlock_slowpath+0x3e/0x340 [40243.633429] ? lock_release+0xd9/0x300 [40243.634052] handle_cap_grant+0xcf6/0x1060 [40243.634745] ceph_handle_caps+0x122b/0x2110 [40243.635415] mds_dispatch+0x5bd/0x2160 [40243.636034] ? ceph_con_process_message+0x65/0x190 [40243.636828] ? lock_release+0xd9/0x300 [40243.637431] ceph_con_process_message+0x7a/0x190 [40243.638184] ? kfree+0x311/0x4f0 [40243.638749] ? kfree+0x311/0x4f0 [40243.639268] process_message+0x16/0x1a0 [40243.639915] ? sg_free_table+0x39/0x90 [40243.640572] ceph_con_v2_try_read+0xf58/0x2120 [40243.641255] ? lock_acquire+0xc8/0x300 [40243.641863] ceph_con_workfn+0x151/0x820 [40243.642493] process_one_work+0x22f/0x630 [40243.643093] ? process_one_work+0x254/0x630 [40243.643770] worker_thread+0x1e2/0x400 [40243.644332] ? __pfx_worker_thread+0x10/0x10 [40243.645020] kthread+0x109/0x140 [40243.645560] ? __pfx_kthread+0x10/0x10 [40243.646125] ret_from_fork+0x3f8/0x480 [40243.646752] ? __pfx_kthread+0x10/0x10 [40243.647316] ? __pfx_kthread+0x10/0x10 [40243.647919] ret_from_fork_asm+0x1a/0x30 [40243.648556] </TASK> [40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore [40243.654766] ---[ end trace 0000000000000000 ]--- Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size") moved the required_blob_size computation to before the __build_xattrs() call, introducing a race. __build_xattrs() releases and reacquires i_ceph_lock during execution. In that window, handle_cap_grant() may update i_xattrs.blob with a newer MDS-provided blob and bump i_xattrs.version. When __build_xattrs() detects that index_version < version, it destroys and rebuilds the entire xattr rb-tree from the new blob, potentially increasing count, names_size, and vals_size. The prealloc_blob size check that follows still uses the stale required_blob_size computed before the rebuild, so it passes even when prealloc_blob is too small for the now-larger tree. After __set_xattr() adds one more xattr on top, __ceph_build_xattrs_blob() is called from the cap flush path and hits: BUG_ON(need > ci->i_xattrs.prealloc_blob->alloc_len); Fix this by recomputing required_blob_size after __build_xattrs() returns, using the current tree state. Also re-validate against m_max_xattr_size to fall back to the sync path if the rebuilt tree now exceeds the MDS limit. Cc: stable(a)vger.kernel.org Fixes: d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size") Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko(a)ibm.com> Reviewed-by: Alex Markuze <amarkuze(a)redhat.com> Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Conflicts: fs/ceph/xattr.c [Use dout to print log instead of doutc due to unmerged commit 38d46409c463 ("ceph: print cluster fsid and client global_id in all debug logs")] Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- fs/ceph/xattr.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/fs/ceph/xattr.c b/fs/ceph/xattr.c index 6fd6a652499e..3920aa4e40a8 100644 --- a/fs/ceph/xattr.c +++ b/fs/ceph/xattr.c @@ -1238,10 +1238,26 @@ int __ceph_setxattr(struct inode *inode, const char *name, dout("setxattr %p name '%s' issued %s\n", inode, name, ceph_cap_string(issued)); __build_xattrs(inode); + /* + * __build_xattrs() may have released and reacquired i_ceph_lock, + * during which handle_cap_grant() could have replaced i_xattrs.blob + * with a newer MDS-provided blob and bumped i_xattrs.version. If that + * caused __build_xattrs() to rebuild the rb-tree from the new blob, + * count/names_size/vals_size may now be larger than when + * required_blob_size was computed above. Recompute it here so the + * prealloc_blob size check below reflects the current tree state. + */ + required_blob_size = __get_required_blob_size(ci, name_len, val_len); + if (required_blob_size > mdsc->mdsmap->m_max_xattr_size) { + dout("%s sync (size too large): %d > %llu\n", __func__, + required_blob_size, mdsc->mdsmap->m_max_xattr_size); + goto do_sync; + } + if (!ci->i_xattrs.prealloc_blob || required_blob_size > ci->i_xattrs.prealloc_blob->alloc_len) { struct ceph_buffer *blob; spin_unlock(&ci->i_ceph_lock); -- 2.34.1

2 1

[PATCH OLK-5.10] USB: serial: kl5kusb105: fix bulk-out buffer overflow
by Jinjie Ruan 01 Jul '26

01 Jul '26

From: HyeongJun An <sammiee5311(a)gmail.com> stable inclusion from stable-v6.6.143 commit a1288cd700f721c1a119c4f1e8efa234e59caada category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15880 CVE: CVE-2026-53194 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 96d47e40bf9db4a9efd5c8fb53287a508d165f14 upstream. klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied. Fixes: 60b3013cdaf3 ("USB: kl5usb105: reimplement using generic framework") Cc: stable(a)vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An <sammiee5311(a)gmail.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- drivers/usb/serial/kl5kusb105.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/kl5kusb105.c b/drivers/usb/serial/kl5kusb105.c index 5f6b82ebccc5..1534ba2b88b4 100644 --- a/drivers/usb/serial/kl5kusb105.c +++ b/drivers/usb/serial/kl5kusb105.c @@ -359,8 +359,8 @@ static int klsi_105_prepare_write_buffer(struct usb_serial_port *port, unsigned char *buf = dest; int count; - count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, - &port->lock); + count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, + size - KLSI_HDR_LEN, &port->lock); put_unaligned_le16(count, buf); return count + KLSI_HDR_LEN; -- 2.34.1

2 1

[PATCH OLK-6.6] USB: serial: kl5kusb105: fix bulk-out buffer overflow
by Jinjie Ruan 01 Jul '26

01 Jul '26

From: HyeongJun An <sammiee5311(a)gmail.com> stable inclusion from stable-v6.6.143 commit a1288cd700f721c1a119c4f1e8efa234e59caada category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15880 CVE: CVE-2026-53194 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 96d47e40bf9db4a9efd5c8fb53287a508d165f14 upstream. klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied. Fixes: 60b3013cdaf3 ("USB: kl5usb105: reimplement using generic framework") Cc: stable(a)vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An <sammiee5311(a)gmail.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- drivers/usb/serial/kl5kusb105.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/kl5kusb105.c b/drivers/usb/serial/kl5kusb105.c index 394b3189e003..b86900fe4a1b 100644 --- a/drivers/usb/serial/kl5kusb105.c +++ b/drivers/usb/serial/kl5kusb105.c @@ -331,8 +331,8 @@ static int klsi_105_prepare_write_buffer(struct usb_serial_port *port, unsigned char *buf = dest; int count; - count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, - &port->lock); + count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, + size - KLSI_HDR_LEN, &port->lock); put_unaligned_le16(count, buf); return count + KLSI_HDR_LEN; -- 2.34.1

2 1

[PATCH OLK-6.6] ipc: limit next_id allocation to the valid ID range
by Fanhua Li 01 Jul '26

01 Jul '26

From: Linpu Yu <linpu5433(a)gmail.com> stable inclusion from stable-v6.6.143 commit 157ce2c6836ce0ff19108a819f38df061345425f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15641 CVE: CVE-2026-52923 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit fa0b9b2b7ae3539908d69c2b9ac0d144d9bc5139 upstream. The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted. Link: https://lore.kernel.org/cover.1778336914.git.linpu5433@gmail.com Link: https://lore.kernel.org/2eebe949bfa7d1f6e13b5be6a92c64c850ce9d45.1778336914… Fixes: 03f595668017 ("ipc: add sysctl to specify desired next object id") Signed-off-by: Linpu Yu <linpu5433(a)gmail.com> Signed-off-by: Ren Wei <n05ec(a)lzu.edu.cn> Reported-by: Yuan Tan <yuantan098(a)gmail.com> Reported-by: Yifan Wu <yifanwucs(a)gmail.com> Reported-by: Juefei Pu <tomapufckgml(a)gmail.com> Reported-by: Xin Liu <bird(a)lzu.edu.cn> Cc: Kees Cook <kees(a)kernel.org> Cc: Stanislav Kinsbursky <skinsbursky(a)parallels.com> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Fanhua Li <lifanhua5(a)huawei.com> --- ipc/util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipc/util.c b/ipc/util.c index 05cb9de667350..14dec7e9c887c 100644 --- a/ipc/util.c +++ b/ipc/util.c @@ -253,7 +253,7 @@ static inline int ipc_idr_alloc(struct ipc_ids *ids, struct kern_ipc_perm *new) } else { new->seq = ipcid_to_seqx(next_id); idx = idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), - 0, GFP_NOWAIT); + ipc_mni, GFP_NOWAIT); } if (idx >= 0) new->id = (new->seq << ipcmni_seq_shift()) + idx; -- 2.43.0

2 1

[PATCH] vdpa: use generic driver_override infrastructure
by Lin Ruifeng 01 Jul '26

01 Jul '26

From: Danilo Krummrich <dakr(a)kernel.org> stable inclusion from stable-v6.18.33 commit 654ef9c33e138ede6734ac286282df9faf83cd11 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15815 CVE: CVE-2026-53118 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 85bb534ff12aab6916058897b39c748940a7a4c6 ] When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1] Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1] Reported-by: Gui-Dong Han <hanguidong02(a)gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789 Fixes: 539fec78edb4 ("vdpa: add driver_override support") Acked-by: Eugenio Pérez <eperezma(a)redhat.com> Acked-by: Michael S. Tsirkin <mst(a)redhat.com> Link: https://patch.msgid.link/20260324005919.2408620-9-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/vdpa/vdpa.c include/linux/vdpa.h [Context Conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/vdpa/vdpa.c | 48 +++++--------------------------------------- include/linux/vdpa.h | 4 ---- 2 files changed, 5 insertions(+), 47 deletions(-) diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c index a7612e0783b3..28a2fb1d0fa4 100644 --- a/drivers/vdpa/vdpa.c +++ b/drivers/vdpa/vdpa.c @@ -67,57 +67,20 @@ static void vdpa_dev_remove(struct device *d) static int vdpa_dev_match(struct device *dev, struct device_driver *drv) { - struct vdpa_device *vdev = dev_to_vdpa(dev); + int ret; /* Check override first, and if set, only use the named driver */ - if (vdev->driver_override) - return strcmp(vdev->driver_override, drv->name) == 0; + ret = device_match_driver_override(dev, drv); + if (ret >= 0) + return ret; /* Currently devices must be supported by all vDPA bus drivers */ return 1; } -static ssize_t driver_override_store(struct device *dev, - struct device_attribute *attr, - const char *buf, size_t count) -{ - struct vdpa_device *vdev = dev_to_vdpa(dev); - int ret; - - ret = driver_set_override(dev, &vdev->driver_override, buf, count); - if (ret) - return ret; - - return count; -} - -static ssize_t driver_override_show(struct device *dev, - struct device_attribute *attr, char *buf) -{ - struct vdpa_device *vdev = dev_to_vdpa(dev); - ssize_t len; - - device_lock(dev); - len = snprintf(buf, PAGE_SIZE, "%s\n", vdev->driver_override); - device_unlock(dev); - - return len; -} -static DEVICE_ATTR_RW(driver_override); - -static struct attribute *vdpa_dev_attrs[] = { - &dev_attr_driver_override.attr, - NULL, -}; - -static const struct attribute_group vdpa_dev_group = { - .attrs = vdpa_dev_attrs, -}; -__ATTRIBUTE_GROUPS(vdpa_dev); - static struct bus_type vdpa_bus = { .name = "vdpa", - .dev_groups = vdpa_dev_groups, + .driver_override = true, .match = vdpa_dev_match, .probe = vdpa_dev_probe, .remove = vdpa_dev_remove, @@ -132,7 +95,6 @@ static void vdpa_release_dev(struct device *d) ops->free(vdev); ida_simple_remove(&vdpa_index_ida, vdev->index); - kfree(vdev->driver_override); kfree(vdev); } diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h index 3120a1a600dd..f16a2647e1cc 100644 --- a/include/linux/vdpa.h +++ b/include/linux/vdpa.h @@ -70,9 +70,6 @@ struct vdpa_mgmt_dev; * struct vdpa_device - representation of a vDPA device * @dev: underlying device * @dma_dev: the actual device that is performing DMA - * @driver_override: driver name to force a match; do not set directly, - * because core frees it; use driver_set_override() to - * set or clear it. * @config: the configuration ops for this device. * @cf_lock: Protects get and set access to configuration layout. * @index: device index @@ -87,7 +84,6 @@ struct vdpa_mgmt_dev; struct vdpa_device { struct device dev; struct device *dma_dev; - const char *driver_override; const struct vdpa_config_ops *config; struct rw_semaphore cf_lock; /* Protects get/set config */ unsigned int index; -- 2.34.1

1 0