- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] xfs: fix freemap adjustments when adding xattrs to leaf blocks
by Long Li 18 Jun '26

18 Jun '26

From: "Darrick J. Wong" <djwong(a)kernel.org> stable inclusion from stable-v5.10.251 commit d08976725355b9d54d8332fce223fa281cc304a5 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14828 CVE: CVE-2026-43158 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit 3eefc0c2b78444b64feeb3783c017d6adc3cd3ce ] xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and the previous patch that resets zero length freemap entries to have base = 0. Cc: <stable(a)vger.kernel.org> # v2.6.12 Fixes: 1da177e4c3f415 ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lin Yujun <linyujun809(a)h-partners.com> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/libxfs/xfs_attr_leaf.c | 36 +++++++++++++++++++++++++++-------- 1 file changed, 28 insertions(+), 8 deletions(-) diff --git a/fs/xfs/libxfs/xfs_attr_leaf.c b/fs/xfs/libxfs/xfs_attr_leaf.c index 3954bf017c8d..3da4643b26cb 100644 --- a/fs/xfs/libxfs/xfs_attr_leaf.c +++ b/fs/xfs/libxfs/xfs_attr_leaf.c @@ -1472,6 +1472,7 @@ xfs_attr3_leaf_add_work( struct xfs_attr_leaf_name_local *name_loc; struct xfs_attr_leaf_name_remote *name_rmt; struct xfs_mount *mp; + int old_end, new_end; int tmp; int i; @@ -1563,17 +1564,36 @@ xfs_attr3_leaf_add_work( if (be16_to_cpu(entry->nameidx) < ichdr->firstused) ichdr->firstused = be16_to_cpu(entry->nameidx); - ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) - + xfs_attr3_leaf_hdr_size(leaf)); - tmp = (ichdr->count - 1) * sizeof(xfs_attr_leaf_entry_t) - + xfs_attr3_leaf_hdr_size(leaf); + new_end = ichdr->count * sizeof(struct xfs_attr_leaf_entry) + + xfs_attr3_leaf_hdr_size(leaf); + old_end = new_end - sizeof(struct xfs_attr_leaf_entry); + + ASSERT(ichdr->firstused >= new_end); for (i = 0; i < XFS_ATTR_LEAF_MAPSIZE; i++) { - if (ichdr->freemap[i].base == tmp) { - ichdr->freemap[i].base += sizeof(xfs_attr_leaf_entry_t); + int diff = 0; + + if (ichdr->freemap[i].base == old_end) { + /* + * This freemap entry starts at the old end of the + * leaf entry array, so we need to adjust its base + * upward to accomodate the larger array. + */ + diff = sizeof(struct xfs_attr_leaf_entry); + } else if (ichdr->freemap[i].size > 0 && + ichdr->freemap[i].base < new_end) { + /* + * This freemap entry starts in the space claimed by + * the new leaf entry. Adjust its base upward to + * reflect that. + */ + diff = new_end - ichdr->freemap[i].base; + } + + if (diff) { + ichdr->freemap[i].base += diff; ichdr->freemap[i].size -= - min_t(uint16_t, ichdr->freemap[i].size, - sizeof(xfs_attr_leaf_entry_t)); + min_t(uint16_t, ichdr->freemap[i].size, diff); } /* -- 2.52.0

2 1

[PATCH OLK-6.6] nvmet-tcp: fix race between ICReq handling and queue teardown
by Long Li 18 Jun '26

18 Jun '26

From: Chaitanya Kulkarni <kch(a)nvidia.com> mainline inclusion from mainline-v7.0-rc3 commit 5293a8882c549fab4a878bc76b0b6c951f980a61 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15382 CVE: CVE-2026-46135 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes. Fixes: c46a6465bac2 ("nvmet-tcp: add NVMe over TCP target driver") Cc: stable(a)vger.kernel.org Reported-by: Shivam Kumar <skumar47(a)syr.edu> Tested-by: Shivam Kumar <kumar.shivam43666(a)gmail.com> Signed-off-by: Chaitanya Kulkarni <kch(a)nvidia.com> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Conflicts: drivers/nvme/target/tcp.c [not merge main commit 675b453e0241 ("nvmet-tcp: enable TLS handshake upcall")] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- drivers/nvme/target/tcp.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c index 5f85c4a812ab..6ec6912b2b47 100644 --- a/drivers/nvme/target/tcp.c +++ b/drivers/nvme/target/tcp.c @@ -389,6 +389,19 @@ static void nvmet_tcp_fatal_error(struct nvmet_tcp_queue *queue) static void nvmet_tcp_socket_error(struct nvmet_tcp_queue *queue, int status) { + /* + * Keep rcv_state at RECV_ERR even for the internal -ESHUTDOWN path. + * nvmet_tcp_handle_icreq() can return -ESHUTDOWN after the ICReq has + * already been consumed and queue teardown has started. + * + * If nvmet_tcp_data_ready() or nvmet_tcp_write_space() queues + * nvmet_tcp_io_work() again before nvmet_tcp_release_queue_work() + * cancels it, the queue must not keep that old receive state. + * Otherwise the next nvmet_tcp_io_work() run can reach + * nvmet_tcp_done_recv_pdu() and try to handle the same ICReq again. + * + * That is why queue->rcv_state needs to be updated before we return. + */ queue->rcv_state = NVMET_TCP_RECV_ERR; if (status == -EPIPE || status == -ECONNRESET) kernel_sock_shutdown(queue->sock, SHUT_RDWR); @@ -938,7 +951,14 @@ static int nvmet_tcp_handle_icreq(struct nvmet_tcp_queue *queue) if (ret < 0) return ret; /* queue removal will cleanup */ + spin_lock_bh(&queue->state_lock); + if (queue->state == NVMET_TCP_Q_DISCONNECTING) { + spin_unlock_bh(&queue->state_lock); + /* Tell nvmet_tcp_socket_error() teardown is in progress. */ + return -ESHUTDOWN; + } queue->state = NVMET_TCP_Q_LIVE; + spin_unlock_bh(&queue->state_lock); nvmet_prepare_receive_pdu(queue); return 0; } -- 2.52.0

2 1

[PATCH OLK-5.10] nvmet-tcp: fix race between ICReq handling and queue teardown
by Long Li 18 Jun '26

18 Jun '26

From: Chaitanya Kulkarni <kch(a)nvidia.com> mainline inclusion from mainline-v7.0-rc3 commit 5293a8882c549fab4a878bc76b0b6c951f980a61 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15382 CVE: CVE-2026-46135 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes. Fixes: c46a6465bac2 ("nvmet-tcp: add NVMe over TCP target driver") Cc: stable(a)vger.kernel.org Reported-by: Shivam Kumar <skumar47(a)syr.edu> Tested-by: Shivam Kumar <kumar.shivam43666(a)gmail.com> Signed-off-by: Chaitanya Kulkarni <kch(a)nvidia.com> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Conflicts: drivers/nvme/target/tcp.c [not merge main commit 675b453e0241 ("nvmet-tcp: enable TLS handshake upcall")] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- drivers/nvme/target/tcp.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c index 6b506783ea4f..1f048ad19f6a 100644 --- a/drivers/nvme/target/tcp.c +++ b/drivers/nvme/target/tcp.c @@ -354,6 +354,19 @@ static void nvmet_tcp_fatal_error(struct nvmet_tcp_queue *queue) static void nvmet_tcp_socket_error(struct nvmet_tcp_queue *queue, int status) { + /* + * Keep rcv_state at RECV_ERR even for the internal -ESHUTDOWN path. + * nvmet_tcp_handle_icreq() can return -ESHUTDOWN after the ICReq has + * already been consumed and queue teardown has started. + * + * If nvmet_tcp_data_ready() or nvmet_tcp_write_space() queues + * nvmet_tcp_io_work() again before nvmet_tcp_release_queue_work() + * cancels it, the queue must not keep that old receive state. + * Otherwise the next nvmet_tcp_io_work() run can reach + * nvmet_tcp_done_recv_pdu() and try to handle the same ICReq again. + * + * That is why queue->rcv_state needs to be updated before we return. + */ queue->rcv_state = NVMET_TCP_RECV_ERR; if (status == -EPIPE || status == -ECONNRESET) kernel_sock_shutdown(queue->sock, SHUT_RDWR); @@ -890,7 +903,14 @@ static int nvmet_tcp_handle_icreq(struct nvmet_tcp_queue *queue) if (ret < 0) return ret; /* queue removal will cleanup */ + spin_lock_bh(&queue->state_lock); + if (queue->state == NVMET_TCP_Q_DISCONNECTING) { + spin_unlock_bh(&queue->state_lock); + /* Tell nvmet_tcp_socket_error() teardown is in progress. */ + return -ESHUTDOWN; + } queue->state = NVMET_TCP_Q_LIVE; + spin_unlock_bh(&queue->state_lock); nvmet_prepare_receive_pdu(queue); return 0; } -- 2.52.0

2 1

[PATCH OLK-6.6 0/3] Fix CVE-2026-31453
by Long Li 18 Jun '26

18 Jun '26

Fix CVE-2026-31453 Long Li (1): Revert "xfs: fix a UAF when inode item push" Yuto Ohnuki (2): xfs: save ailp before dropping the AIL lock in push callbacks xfs: avoid dereferencing log items after push callbacks fs/xfs/xfs_dquot_item.c | 9 +++++++-- fs/xfs/xfs_inode_item.c | 17 ++++++++--------- fs/xfs/xfs_trace.h | 36 ++++++++++++++++++++++++++++++++---- fs/xfs/xfs_trans_ail.c | 26 +++++++++++++++++++------- 4 files changed, 66 insertions(+), 22 deletions(-) -- 2.52.0

2 4

[PATCH OLK-5.10] xfs: stop reclaim before pushing AIL during unmount
by Long Li 17 Jun '26

17 Jun '26

From: Yuto Ohnuki <ytohnuki(a)amazon.com> stable inclusion from stable-v5.10.252 commit e6cc490048f78b009259a5f032acead9f789c34c category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14197 CVE: CVE-2026-31455 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit 4f24a767e3d64a5f58c595b5c29b6063a201f1e3 ] The unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while background reclaim and inodegc are still running. This is broken independently of any use-after-free issues - background reclaim and inodegc should not be running while the AIL is being pushed during unmount, as inodegc can dirty and insert inodes into the AIL during the flush, and background reclaim can race to abort and free dirty inodes. Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel background reclaim before pushing the AIL. Stop inodegc before cancelling m_reclaim_work because the inodegc worker can re-queue m_reclaim_work via xfs_inodegc_set_reclaimable. Reported-by: syzbot+652af2b3c5569c4ab63c(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=652af2b3c5569c4ab63c Fixes: 90c60e164012 ("xfs: xfs_iflush() is no longer necessary") Cc: stable(a)vger.kernel.org # v5.9 Signed-off-by: Yuto Ohnuki <ytohnuki(a)amazon.com> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> [ dropped xfs_inodegc_stop() call ] Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: fs/xfs/xfs_mount.c [Context conflicts] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/xfs_mount.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index 4983fe7eadf0..cb99ac78d904 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -687,8 +687,9 @@ xfs_ifree_unmount( * have been retrying in the background. This will prevent never-ending * retries in AIL pushing from hanging the unmount. * - * Finally, we can push the AIL to clean all the remaining dirty objects, then - * reclaim the remaining inodes that are still in memory at this point in time. + * Stop inodegc and background reclaim before pushing the AIL so that they + * are not running while the AIL is being flushed. Then push the AIL to + * clean all the remaining dirty objects and reclaim the remaining inodes. */ static void xfs_unmount_flush_inodes( @@ -700,9 +701,9 @@ xfs_unmount_flush_inodes( set_bit(XFS_OPSTATE_UNMOUNTING, &mp->m_opstate); - xfs_ail_push_all_sync(mp->m_ail); xfs_inodegc_stop(mp); cancel_delayed_work_sync(&mp->m_reclaim_work); + xfs_ail_push_all_sync(mp->m_ail); xfs_reclaim_inodes(mp); xfs_health_unmount(mp); } -- 2.52.0

2 1

[PATCH OLK-5.10 0/3] Fix CVE-2026-31453
by Long Li 17 Jun '26

17 Jun '26

Fix CVE-2026-31453. Long Li (1): Revert "xfs: fix a UAF when inode item push" Yuto Ohnuki (2): xfs: avoid dereferencing log items after push callbacks xfs: save ailp before dropping the AIL lock in push callbacks fs/xfs/xfs_dquot_item.c | 9 ++++-- fs/xfs/xfs_inode_item.c | 17 ++++++----- fs/xfs/xfs_trace.c | 1 + fs/xfs/xfs_trace.h | 63 ++++++++++++++++++++--------------------- fs/xfs/xfs_trans_ail.c | 26 ++++++++++++----- 5 files changed, 66 insertions(+), 50 deletions(-) -- 2.52.0

2 4

[PATCH OLK-5.10] xfs: delete attr leaf freemap entries when empty
by Long Li 17 Jun '26

17 Jun '26

From: "Darrick J. Wong" <djwong(a)kernel.org> stable inclusion from stable-v5.10.251 commit f3c0d1fc1eadbb4adbee5ab7757d41d35f48325b category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14733 CVE: CVE-2026-43187 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit 6f13c1d2a6271c2e73226864a0e83de2770b6f34 ] Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the "pushed-up" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap. It looks like this bug has been in the codebase for quite a long time. Cc: <stable(a)vger.kernel.org> # v2.6.12 Fixes: 1da177e4c3f415 ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/libxfs/xfs_attr_leaf.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/fs/xfs/libxfs/xfs_attr_leaf.c b/fs/xfs/libxfs/xfs_attr_leaf.c index e953bc44d4d0..3954bf017c8d 100644 --- a/fs/xfs/libxfs/xfs_attr_leaf.c +++ b/fs/xfs/libxfs/xfs_attr_leaf.c @@ -1575,6 +1575,19 @@ xfs_attr3_leaf_add_work( min_t(uint16_t, ichdr->freemap[i].size, sizeof(xfs_attr_leaf_entry_t)); } + + /* + * Don't leave zero-length freemaps with nonzero base lying + * around, because we don't want the code in _remove that + * matches on base address to get confused and create + * overlapping freemaps. If we end up with no freemap entries + * then the next _add will compact the leaf block and + * regenerate the freemaps. + */ + if (ichdr->freemap[i].size == 0 && ichdr->freemap[i].base > 0) { + ichdr->freemap[i].base = 0; + ichdr->holes = 1; + } } ichdr->usedbytes += xfs_attr_leaf_entsize(leaf, args->index); return 0; -- 2.52.0

2 1

[PATCH OLK-5.10] fuse: reject oversized dirents in page cache
by Long Li 17 Jun '26

17 Jun '26

From: Samuel Page <sam(a)bynar.io> mainline inclusion from mainline-v7.0 commit 51a8de6c50bf947c8f534cd73da4c8f0a13e7bed category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14444 CVE: CVE-2026-31694 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE. As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page. Reject dirents that cannot fit in a single page before copying them into the readdir cache. Fixes: 69e34551152a ("fuse: allow caching readdir") Cc: stable(a)vger.kernel.org # v6.16+ Assisted-by: Bynario AI Signed-off-by: Samuel Page <sam(a)bynar.io> Reported-by: Qi Tang <tpluszz77(a)gmail.com> Reported-by: Zijun Hu <nightu(a)northwestern.edu> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Link: https://patch.msgid.link/20260420090139.662772-1-mszeredi@redhat.com Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/fuse/readdir.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/fuse/readdir.c b/fs/fuse/readdir.c index f18632027d8b..00b2fc180bc7 100644 --- a/fs/fuse/readdir.c +++ b/fs/fuse/readdir.c @@ -41,6 +41,10 @@ static void fuse_add_dirent_to_cache(struct file *file, unsigned int offset; void *addr; + /* Dirent doesn't fit in readdir cache page? Skip caching. */ + if (reclen > PAGE_SIZE) + return; + spin_lock(&fi->rdc.lock); /* * Is cache already completed? Or this entry does not go at the end of -- 2.52.0

2 1

[PATCH OLK-5.10] ntfs: ->d_compare() must not block
by Yifan Qiao 17 Jun '26

17 Jun '26

From: Al Viro <viro(a)zeniv.linux.org.uk> mainline inclusion from mainline-v7.0-rc1 commit ca2a04e84af79596e5cd9cfe697d5122ec39c8ce category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14789 CVE: CVE-2026-43245 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX. Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/ntfs3/dir.c | 5 ++--- fs/ntfs3/inode.c | 12 ++++++------ fs/ntfs3/namei.c | 9 ++++----- fs/ntfs3/xattr.c | 4 ++-- 4 files changed, 14 insertions(+), 16 deletions(-) diff --git a/fs/ntfs3/dir.c b/fs/ntfs3/dir.c index fb438d604040..27713367aa64 100644 --- a/fs/ntfs3/dir.c +++ b/fs/ntfs3/dir.c @@ -390,8 +390,7 @@ static int ntfs_readdir(struct file *file, struct dir_context *ctx) if (!dir_emit_dots(file, ctx)) return 0; - /* Allocate PATH_MAX bytes. */ - name = __getname(); + name = kmalloc(PATH_MAX, GFP_KERNEL); if (!name) return -ENOMEM; @@ -470,7 +469,7 @@ static int ntfs_readdir(struct file *file, struct dir_context *ctx) out: - __putname(name); + kfree(name); put_indx_node(node); if (err == -ENOENT) { diff --git a/fs/ntfs3/inode.c b/fs/ntfs3/inode.c index b1849c4c48e1..c582eb08d5f8 100644 --- a/fs/ntfs3/inode.c +++ b/fs/ntfs3/inode.c @@ -1280,7 +1280,7 @@ struct inode *ntfs_create_inode(struct user_namespace *mnt_userns, fa |= FILE_ATTRIBUTE_READONLY; /* Allocate PATH_MAX bytes. */ - new_de = __getname(); + new_de = kzalloc(PATH_MAX, GFP_KERNEL); if (!new_de) { err = -ENOMEM; goto out1; @@ -1653,7 +1653,7 @@ struct inode *ntfs_create_inode(struct user_namespace *mnt_userns, ntfs_mark_rec_free(sbi, ino); out2: - __putname(new_de); + kfree(new_de); kfree(rp); out1: @@ -1676,7 +1676,7 @@ int ntfs_link_inode(struct inode *inode, struct dentry *dentry) struct ATTR_FILE_NAME *de_name; /* Allocate PATH_MAX bytes. */ - de = __getname(); + de = kzalloc(PATH_MAX, GFP_KERNEL); if (!de) return -ENOMEM; @@ -1699,7 +1699,7 @@ int ntfs_link_inode(struct inode *inode, struct dentry *dentry) err = ni_add_name(ntfs_i(d_inode(dentry->d_parent)), ni, de); out: - __putname(de); + kfree(de); return err; } @@ -1723,7 +1723,7 @@ int ntfs_unlink_inode(struct inode *dir, const struct dentry *dentry) return -EINVAL; /* Allocate PATH_MAX bytes. */ - de = __getname(); + de = kzalloc(PATH_MAX, GFP_KERNEL); if (!de) return -ENOMEM; @@ -1761,7 +1761,7 @@ int ntfs_unlink_inode(struct inode *dir, const struct dentry *dentry) out: ni_unlock(ni); - __putname(de); + kfree(de); return err; } diff --git a/fs/ntfs3/namei.c b/fs/ntfs3/namei.c index 18330d982b07..49f5246abfdd 100644 --- a/fs/ntfs3/namei.c +++ b/fs/ntfs3/namei.c @@ -66,7 +66,7 @@ static struct dentry *ntfs_lookup(struct inode *dir, struct dentry *dentry, u32 flags) { struct ntfs_inode *ni = ntfs_i(dir); - struct cpu_str *uni = __getname(); + struct cpu_str *uni = kmalloc(PATH_MAX, GFP_KERNEL); struct inode *inode; int err; @@ -83,7 +83,7 @@ static struct dentry *ntfs_lookup(struct inode *dir, struct dentry *dentry, inode = dir_search_u(dir, uni, NULL); ni_unlock(ni); } - __putname(uni); + kfree(uni); } return d_splice_alias(inode, dentry); @@ -280,8 +280,7 @@ static int ntfs_rename(struct inode *dir, return err; } - /* Allocate PATH_MAX bytes. */ - de = __getname(); + de = kmalloc(PATH_MAX, GFP_KERNEL); if (!de) return -ENOMEM; @@ -325,7 +324,7 @@ static int ntfs_rename(struct inode *dir, ni_unlock(ni); ni_unlock(dir_ni); out: - __putname(de); + kfree(de); return err; } diff --git a/fs/ntfs3/xattr.c b/fs/ntfs3/xattr.c index 24d739000c80..ddec586d4de6 100644 --- a/fs/ntfs3/xattr.c +++ b/fs/ntfs3/xattr.c @@ -533,7 +533,7 @@ static struct posix_acl *ntfs_get_acl_ex(struct user_namespace *mnt_userns, void *buf; /* Allocate PATH_MAX bytes. */ - buf = __getname(); + buf = kmalloc(PATH_MAX, GFP_KERNEL); if (!buf) return ERR_PTR(-ENOMEM); @@ -566,7 +566,7 @@ static struct posix_acl *ntfs_get_acl_ex(struct user_namespace *mnt_userns, if (!IS_ERR(acl)) set_cached_acl(inode, type, acl); - __putname(buf); + kfree(buf); return acl; } -- 2.52.0

2 1

社区update版本合入截止时间和构建时间调整公示
by Xushanshan(Sassa,openEuler) 16 Jun '26

16 Jun '26

Add kernel sig 发件人: Xushanshan(Sassa,openEuler) <xushanshan3(a)huawei.com> 发送时间: 2026年6月16日 23:17 收件人: release(a)openeuler.org 抄送: tc(a)openeuler.org; qa(a)openeuler.org; dev(a)openeuler.org; cicd(a)openeuler.org; kernel(a)openeuler.org 主题: [Dev] 社区update版本合入截止时间和构建时间调整公示 Hi ALL：经RM sig评审，update 版本的构建时间调整为周一合入，周三发布；整体触发背景和结论如下，如有相关的意见，可在06/22前反馈。一：变更背景：社区构建资源紧张，内核&用户态等PR集中提交的情况下，资源冲突，PR高峰期合入要等待2-3小时，构建出包10+小时。从工程能力和版本发布周期等维度讨论了部分优化措施，过程中识别到主干Next分支和update版本发布时间存在重叠（周三12点截止PR合入，周五出版本），资源抢占较多，影响两个版本，因此申请错开两个版本。其他优化措施见四；二：决策结论：社区update版本的PR截止合入时间，调整为周一16点，版本发布时间调整为周三晚；update变更开始执行时间：0622 三：修改后的合入时间建议：版本类型版本 PR截止合入时间版本发布时间内核用户态源码仓制品仓源码仓制品仓开发分支（保持不变） Next主干开发分支(当前24.03 LTS SP4) 周三16：00 周三18：00 / 周三18：00 周五晚维护版本 24.03 LTS SP3 update 周一16:00 周一18：00 / 周一18:00 周三晚 24.03 LTS SP1 update 22.03 LTS SP4 update 20.03 LTS SP4 四：其他工程能力优化措施和进展：问题改进措施进展内核源码编译门禁执行时间长 1、新增蓝区arm物理机集群，对接oe社区Jenkins 2、该集群用于内核源码编译，并根据负载情况进行扩缩容 done 检查类门禁（trigger门禁）排队时间长 1、增加trigger机器资源(done) 2、能自动停止同一个pr中已经失效的但还在排队或者执行中的任务目标730 多个版本集中在同一时间构建，导致EulerMaker负载大，调度慢 1、update版本和SP版本严格管控合入时间，按天错开构建时间(done) 2、EulerMaker进行重构，从架构层面解决调度问题目标930 构建流程存在断连，每个步骤都通过定时触发，而不是前后依赖触发，导致端到端构建总时间过长（20点开始包构建，凌晨6点左右出包，端到端需要10小时） 1、通过Jenkins流水线能力连编排EulerMaker everyting工程构建，ISO镜像构建，EulerMaker epol工程构建，docker镜像和虚拟机镜像构建，openQA测试等全流程，端到端时间缩短到4-6小时 done

1 0