- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10 0/2] nfs: fix invalidate dentries on transient errors
by Long Li 28 Jul '26

28 Jul '26

This patch set fix invalidate dentries on transient errors. Scott Mayhew (1): nfs: don't invalidate dentries on transient errors Trond Myklebust (1): NFS: Trace lookup revalidation failure fs/nfs/dir.c | 44 ++++++++++++++++++-------------------------- 1 file changed, 18 insertions(+), 26 deletions(-) -- 2.52.0

2 3

[PATCH openEuler-1.0-LTS] drm/amd/display: Validate GPIO pin LUT table size before iterating
by Fanhua Li 28 Jul '26

28 Jul '26

From: Harry Wentland <harry.wentland(a)amd.com> stable inclusion from stable-v6.6.142 commit fb30a3890d62fd50a95aef684faf64a307592e42 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16453 CVE: CVE-2026-64097 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 86d2b20644b11d21fe52c596e6e922b4590a3e3f upstream. [Why&How] The GPIO pin table parsers in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() derive an element count from the VBIOS table_header.structuresize field, then iterate over gpio_pin[] entries. However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read. Fix this by calling bios_get_image() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions. Assisted-by: GitHub Copilot:claude-opus-4-6 Reviewed-by: Alex Hung <alex.hung(a)amd.com> Signed-off-by: Harry Wentland <harry.wentland(a)amd.com> Signed-off-by: Ivan Lipski <ivan.lipski(a)amd.com> Tested-by: Dan Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3) Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflict: drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c [Fanhua Li: context conflict] Signed-off-by: Fanhua Li <lifanhua5(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c index eab007e1793c2..827d22b73fbcb 100644 --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c @@ -446,6 +446,10 @@ static enum bp_result get_gpio_i2c_info( - sizeof(struct atom_common_table_header)) / sizeof(struct atom_gpio_pin_assignment); + if (!bios_get_image(&bp->base, DATA_TABLES(gpio_pin_lut), + le16_to_cpu(header->table_header.structuresize))) + return BP_RESULT_BADBIOSTABLE; + table_index = record->i2c_id & I2C_HW_LANE_MUX; if (count < table_index) { @@ -705,6 +709,11 @@ static enum bp_result bios_parser_get_gpio_pin_info( - sizeof(struct atom_common_table_header)) / sizeof(struct atom_gpio_pin_assignment); #endif + + if (!bios_get_image(&bp->base, DATA_TABLES(gpio_pin_lut), + le16_to_cpu(header->table_header.structuresize))) + return BP_RESULT_BADBIOSTABLE; + for (i = 0; i < count; ++i) { if (header->gpio_pin[i].gpio_id != gpio_id) continue; -- 2.43.0

2 1

[PATCH OLK-5.10] drm/amd/display: Validate GPIO pin LUT table size before iterating
by Fanhua Li 28 Jul '26

28 Jul '26

From: Harry Wentland <harry.wentland(a)amd.com> stable inclusion from stable-v6.6.142 commit fb30a3890d62fd50a95aef684faf64a307592e42 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16453 CVE: CVE-2026-64097 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 86d2b20644b11d21fe52c596e6e922b4590a3e3f upstream. [Why&How] The GPIO pin table parsers in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() derive an element count from the VBIOS table_header.structuresize field, then iterate over gpio_pin[] entries. However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read. Fix this by calling bios_get_image() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions. Assisted-by: GitHub Copilot:claude-opus-4-6 Reviewed-by: Alex Hung <alex.hung(a)amd.com> Signed-off-by: Harry Wentland <harry.wentland(a)amd.com> Signed-off-by: Ivan Lipski <ivan.lipski(a)amd.com> Tested-by: Dan Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3) Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c [Fanhua Li: context conflict] Signed-off-by: Fanhua Li <lifanhua5(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c index 9dd41eaf32cb5..2f6c49af7f8e3 100644 --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c @@ -380,6 +380,10 @@ static enum bp_result get_gpio_i2c_info( - sizeof(struct atom_common_table_header)) / sizeof(struct atom_gpio_pin_assignment); + if (!bios_get_image(&bp->base, DATA_TABLES(gpio_pin_lut), + le16_to_cpu(header->table_header.structuresize))) + return BP_RESULT_BADBIOSTABLE; + pin = (struct atom_gpio_pin_assignment *) header->gpio_pin; for (table_index = 0; table_index < count; table_index++) { @@ -535,6 +539,11 @@ static enum bp_result bios_parser_get_gpio_pin_info( - sizeof(struct atom_common_table_header)) / sizeof(struct atom_gpio_pin_assignment); #endif + + if (!bios_get_image(&bp->base, DATA_TABLES(gpio_pin_lut), + le16_to_cpu(header->table_header.structuresize))) + return BP_RESULT_BADBIOSTABLE; + for (i = 0; i < count; ++i) { if (header->gpio_pin[i].gpio_id != gpio_id) continue; -- 2.43.0

2 1

[PATCH OLK-6.6] ftrace: Add global mutex to serialize trace_parser access
by Tengda Wu 27 Jul '26

27 Jul '26

From: Tengda Wu <wutengda(a)huaweicloud.com> mainline inclusion from mainline-v7.2-rc5 commit 7720b63bcef3f54c7fe288774b720a227d54a306 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9672 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state. Fixes: e704eff3ff51 ("ftrace: Have set_graph_function handle multiple functions in one write") Fixes: 689fd8b65d66 ("tracing: trace parser support for function and graph") Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20260725024721.1983675-1-wutengda@huaweicloud.com Signed-off-by: Tengda Wu <wutengda(a)huaweicloud.com> Signed-off-by: Steven Rostedt <rostedt(a)goodmis.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/trace/ftrace.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 94f7ed57d43e..a575c1237420 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -1067,6 +1067,12 @@ struct ftrace_ops global_ops = { FTRACE_OPS_FL_PID, }; +/* + * parser_lock - Protects trace_parser state against concurrent operations. + * Held across trace_get_user() and subsequent buffer parsing to prevent races. + */ +static DEFINE_MUTEX(parser_lock); + /* * Used by the stack unwinder to know about dynamic ftrace trampolines. */ @@ -5202,6 +5208,8 @@ ftrace_regex_write(struct file *file, const char __user *ubuf, /* iter->hash is a local copy, so we don't need regex_lock */ parser = &iter->parser; + + guard(mutex)(&parser_lock); read = trace_get_user(parser, ubuf, cnt, ppos); if (read >= 0 && trace_parser_loaded(parser) && @@ -5927,12 +5935,14 @@ int ftrace_regex_release(struct inode *inode, struct file *file) iter = file->private_data; parser = &iter->parser; + mutex_lock(&parser_lock); if (trace_parser_loaded(parser)) { int enable = !(iter->flags & FTRACE_ITER_NOTRACE); ftrace_process_regex(iter, parser->buffer, parser->idx, enable); } + mutex_unlock(&parser_lock); trace_parser_put(parser); @@ -6264,10 +6274,12 @@ ftrace_graph_release(struct inode *inode, struct file *file) parser = &fgd->parser; + mutex_lock(&parser_lock); if (trace_parser_loaded((parser))) { ret = ftrace_graph_set_hash(fgd->new_hash, parser->buffer); } + mutex_unlock(&parser_lock); trace_parser_put(parser); @@ -6387,6 +6399,7 @@ ftrace_graph_write(struct file *file, const char __user *ubuf, parser = &fgd->parser; + guard(mutex)(&parser_lock); read = trace_get_user(parser, ubuf, cnt, ppos); if (read >= 0 && trace_parser_loaded(parser) && -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/2] Fix CVE-2026-64378
by Zizhi Wo 27 Jul '26

27 Jul '26

Fix CVE-2026-64378 Baokun Li (1): writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs() Tejun Heo (1): writeback, cgroup: inode_switch_wbs() shouldn't give up on wb_switch_rwsem trylock fail fs/fs-writeback.c | 38 ++++++++++++++++++++++++-------------- 1 file changed, 24 insertions(+), 14 deletions(-) -- 2.52.0

2 3

[PATCH OLK-6.6 0/4] Fix CVE-2026-64378
by Zizhi Wo 27 Jul '26

27 Jul '26

Fix CVE-2026-64378 Baokun Li (2): writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs() writeback: drop now-unnecessary rcu_barrier() in cgroup_writeback_umount() Jan Kara (2): writeback: Avoid contention on wb->list_lock when switching inodes writeback: Fix use after free in inode_switch_wbs_work_fn() fs/fs-writeback.c | 133 +++++++++++++++++++++---------- include/linux/backing-dev-defs.h | 4 + include/linux/writeback.h | 2 + mm/backing-dev.c | 5 ++ 4 files changed, 103 insertions(+), 41 deletions(-) -- 2.52.0

2 5

[PATCH OLK-6.6 0/3] Fix CVE-2026-64378
by Zizhi Wo 27 Jul '26

27 Jul '26

Fix CVE-2026-64378 Baokun Li (1): writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs() Jan Kara (2): writeback: Avoid contention on wb->list_lock when switching inodes writeback: Fix use after free in inode_switch_wbs_work_fn() fs/fs-writeback.c | 132 ++++++++++++++++++++++--------- include/linux/backing-dev-defs.h | 4 + include/linux/writeback.h | 2 + mm/backing-dev.c | 5 ++ 4 files changed, 105 insertions(+), 38 deletions(-) -- 2.52.0

2 4

[PATCH openEuler-1.0-LTS] PCI: Remove old_size limit from bridge window sizing
by Hongtao Zhang 27 Jul '26

27 Jul '26

From: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> mainline inclusion from mainline-v7.0-rc1 commit f909e3ee3ed1a44202f09ac7e637a0f9ec372225 category: bugfix bugzilla: 190863 Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit… -------------------------------- calculate_memsize() applies lower bound to the resource size before aligning the resource size making it impossible to shrink bridge window resources. I've not found any justification for this lower bound and nothing indicated it was to work around some HW issue. Prior to the commit 3baeae36039a ("PCI: Use pci_release_resource() instead of release_resource()"), releasing a bridge window during BAR resize resulted in clearing start and end address of the resource. Clearing addresses destroys the resource size as a side-effect, therefore nullifying the effect of the old size lower bound. After the commit 3baeae36039a ("PCI: Use pci_release_resource() instead of release_resource()"), BAR resize uses the aligned old size, which results in exceeding what fits into the parent window in some cases: xe 0030:03:00.0: [drm] Attempting to resize bar from 256MiB -> 16384MiB xe 0030:03:00.0: BAR 0 [mem 0x620c000000000-0x620c000ffffff 64bit]: releasing xe 0030:03:00.0: BAR 2 [mem 0x6200000000000-0x620000fffffff 64bit pref]: releasing pci 0030:02:01.0: bridge window [mem 0x6200000000000-0x620001fffffff 64bit pref]: releasing pci 0030:01:00.0: bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref]: releasing pci 0030:00:00.0: bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref]: was not released (still contains assigned resources) pci 0030:00:00.0: Assigned bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref] to [bus 01-04] free space at [mem 0x6200400000000-0x62007ffffffff 64bit pref] pci 0030:00:00.0: Assigned bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref] to [bus 01-04] cannot fit 0x4000000000 required for 0030:01:00.0 bridging to [bus 02-04] The old size of 0x6200000000000-0x6203fbff0ffff resource was used as the lower bound which results in 0x4000000000 size request due to alignment. That exceeds what can fit into the parent window. Since the lower bound never even was enforced fully because the resource addresses were cleared when the bridge window is released, remove the old_size lower bound entirely and trust the calculated bridge window size is enough. This same problem may occur on io window side but seems less likely to cause issues due to general difference in alignment. Removing the lower bound may have other unforeseen consequences in case of io window so it's better to leave it as -next material if no problem is reported related to io window sizing (BAR resize shouldn't touch io windows anyway). Fixes: 3baeae36039a ("PCI: Use pci_release_resource() instead of release_resource()") Reported-by: Simon Richter <Simon.Richter(a)hogyros.de> Link: https://lore.kernel.org/r/f9a8c975-f5d3-4dd2-988e-4371a1433a60@hogyros.de/ Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Link: https://patch.msgid.link/20251219174036.16738-6-ilpo.jarvinen@linux.intel.c… Conflicts: drivers/pci/setup-bus.c [conflicts due to not mergered prerequisites] Signed-off-by: Zhang Hongtao <zhanghongtao35(a)huawei.com> --- drivers/pci/setup-bus.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 39d19302f3cbe..fe6f68d9e465b 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -794,15 +794,10 @@ static resource_size_t calculate_iosize(resource_size_t size, static resource_size_t calculate_memsize(resource_size_t size, resource_size_t min_size, resource_size_t size1, - resource_size_t old_size, resource_size_t align) { if (size < min_size) size = min_size; - if (old_size == 1) - old_size = 0; - if (size < old_size) - size = old_size; size = ALIGN(size + size1, align); return size; } @@ -1041,13 +1036,12 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask, min_align = calculate_mem_align(aligns, max_order); min_align = max(min_align, window_alignment(bus, b_res->flags)); - size0 = calculate_memsize(size, min_size, 0, resource_size(b_res), min_align); + size0 = calculate_memsize(size, min_size, 0, min_align); add_align = max(min_align, add_align); if (children_add_size > add_size) add_size = children_add_size; size1 = (!realloc_head || (realloc_head && !add_size)) ? size0 : - calculate_memsize(size, min_size, add_size, - resource_size(b_res), add_align); + calculate_memsize(size, min_size, add_size, add_align); if (!size0 && !size1) { if (b_res->start || b_res->end) pci_info(bus->self, "disabling bridge window %pR to %pR (unused)\n", -- 2.43.0

2 1

[PATCH openEuler-1.0-LTS] ext4: avoid infinite loops caused by residual data
by Lai Zewei 27 Jul '26

27 Jul '26

mainline inclusion from mainline-v7.0-rc6 commit 5422fe71d26d42af6c454ca9527faaad4e677d6c category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14191 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- On the mkdir/mknod path, when mapping logical blocks to physical blocks, if inserting a new extent into the extent tree fails (in this example, because the file system disabled the huge file feature when marking the inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to reclaim the physical block without deleting the corresponding data in the extent tree. This causes subsequent mkdir operations to reference the previously reclaimed physical block number again, even though this physical block is already being used by the xattr block. Therefore, a situation arises where both the directory and xattr are using the same buffer head block in memory simultaneously. The above causes ext4_xattr_block_set() to enter an infinite loop about "inserted" and cannot release the inode lock, ultimately leading to the 143s blocking problem mentioned in [1]. If the metadata is corrupted, then trying to remove some extent space can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE was passed, remove space wrongly update quota information. Jan Kara suggests distinguishing between two cases: 1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully consistent and we must maintain its consistency including all the accounting. However these errors can happen only early before we've inserted the extent into the extent tree. So current code works correctly for this case. 2) Some other error - this means metadata is corrupted. We should strive to do as few modifications as possible to limit damage. So I'd just skip freeing of allocated blocks. [1] INFO: task syz.0.17:5995 blocked for more than 143 seconds. Call Trace: inode_lock_nested include/linux/fs.h:1073 [inline] __start_dirop fs/namei.c:2923 [inline] start_dirop fs/namei.c:2934 [inline] Reported-by: syzbot+512459401510e2a9a39f(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7 Tested-by: syzbot+1659aaaaa8d9d11265d7(a)syzkaller.appspotmail.com Reported-by: syzbot+1659aaaaa8d9d11265d7(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=512459401510e2a9a39f Tested-by: syzbot+1659aaaaa8d9d11265d7(a)syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis <eadavis(a)qq.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Tested-by: syzbot+512459401510e2a9a39f(a)syzkaller.appspotmail.com Link: https://patch.msgid.link/tencent_43696283A68450B761D76866C6F360E36705@qq.com Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Cc: stable(a)kernel.org Conflicts: fs/ext4/extents.c [ctx conflicts] Signed-off-by: Lai Zewei <laizewei3(a)huawei.com> --- fs/ext4/extents.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 5f2654bfe2f1..bf1d315f9178 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4672,7 +4672,12 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode, err = ext4_ext_insert_extent(handle, inode, &path, &newex, flags); - if (err && free_on_err) { + /* + * Gracefully handle out of space conditions. If the filesystem + * is inconsistent, we'll just leak allocated blocks to avoid + * causing even more damage. + */ + if (err && free_on_err && (err == -EDQUOT || err == -ENOSPC)) { int fb_flags = flags & EXT4_GET_BLOCKS_DELALLOC_RESERVE ? EXT4_FREE_BLOCKS_NO_QUOT_UPDATE : 0; /* free data blocks we just allocated */ -- 2.52.0

2 3

[PATCH OLK-6.6] smb: client: fix change notify replay double-free
by Lai Zewei 27 Jul '26

27 Jul '26

mainline inclusion from mainline-v7.2-rc1 commit 145f820dcbb2cced374f2532f8a61a44dce4a615 category: bugfix bugzilla: 190875 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_notify_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free. Fixes: 4f1fffa23769 ("cifs: commands that are retried should have replay flag set") Cc: stable(a)vger.kernel.org Signed-off-by: Henrique Carvalho <henrique.carvalho(a)suse.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/smb/client/smb2pdu.c [ctx conflicts] Signed-off-by: Lai Zewei <laizewei3(a)huawei.com> --- fs/smb/client/smb2pdu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c index 6c12f696122f..367c414195d4 100644 --- a/fs/smb/client/smb2pdu.c +++ b/fs/smb/client/smb2pdu.c @@ -4021,6 +4021,8 @@ SMB2_change_notify(const unsigned int xid, struct cifs_tcon *tcon, replay_again: /* reinitialize for possible replay */ + resp_buftype = CIFS_NO_BUFFER; + memset(&rsp_iov, 0, sizeof(rsp_iov)); flags = 0; server = cifs_pick_channel(ses); -- 2.52.0

2 13