- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] security/keys: fix missed RCU read section on lookup
by Yi Yang 24 Jul '26

24 Jul '26

From: Linus Torvalds <torvalds(a)linux-foundation.org> mainline inclusion from mainline-v7.1-rc6 commit 43a1e3744548e6fd85873e6fb43e293eb4010694 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16340 CVE: CVE-2026-64015 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Nicholas Carlini reports that the keyring code calls assoc_array_find() in find_key_to_update() without holding the RCU read lock, while the assoc_array_gc() code really is designed around removing the node from the tree and then freeing it after an RCU grace-period. The regular key handling doesn't see this because holding the keyring semaphore hides any lifetime issues, but the persistent key handling uses a different model. Instead of extending the keyring locking, just do the simple RCU locking that the assoc_array was designed for. Reported-by: Nicholas Carlini <npc(a)anthropic.com> Cc: David Howells <dhowells(a)redhat.com> Cc: Jarkko Sakkinen <jarkko(a)kernel.org> Cc: Paul Moore <paul(a)paul-moore.com> Cc: James Morris James Morris <jmorris(a)namei.org> Cc: Serge E. Hallyn <serge(a)hallyn.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Conflicts: security/keys/keyring.c [Commit 54da6a092431 ("locking: Introduce __cleanup() based infrastructure") was nor merged. The guard() function was not introduced.] Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- security/keys/keyring.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/security/keys/keyring.c b/security/keys/keyring.c index 9f0fc81a3a7b..ba34c97b9f62 100644 --- a/security/keys/keyring.c +++ b/security/keys/keyring.c @@ -1109,12 +1109,14 @@ key_ref_t find_key_to_update(key_ref_t keyring_ref, kenter("{%d},{%s,%s}", keyring->serial, index_key->type->name, index_key->description); + rcu_read_lock(); object = assoc_array_find(&keyring->keys, &keyring_assoc_array_ops, index_key); if (object) goto found; + rcu_read_unlock(); kleave(" = NULL"); return NULL; @@ -1122,10 +1124,12 @@ key_ref_t find_key_to_update(key_ref_t keyring_ref, key = keyring_ptr_to_key(object); if (key->flags & ((1 << KEY_FLAG_INVALIDATED) | (1 << KEY_FLAG_REVOKED))) { + rcu_read_unlock(); kleave(" = NULL [x]"); return NULL; } __key_get(key); + rcu_read_unlock(); kleave(" = {%d}", key->serial); return make_key_ref(key, is_key_possessed(keyring_ref)); } -- 2.25.1

2 1

[PATCH] [OLK-6.6] fuse: re-lock request before replacing page cache folio
by Lu Chentao 24 Jul '26

24 Jul '26

From: Joanne Koong <joannelkoong(a)gmail.com> stable inclusion from stable-v6.6.144 commit 030fe3e9d8abdee303dd7e9e42f45082d382a407 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16108 CVE: CVE-2026-53388 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- [ Upstream commit a078484921052d0badd827fcc2770b5cfc1d4120 ] fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio(). Fixes: ce534fb05292 ("fuse: allow splice to move pages") Cc: stable(a)vger.kernel.org Reported-by: Lei Lu <llfamsec(a)gmail.com> Signed-off-by: Joanne Koong <joannelkoong(a)gmail.com> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lu Chentao <luchentao1(a)huawei.com> --- fs/fuse/dev.c | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c index 75c067522c98..f197909aee8d 100644 --- a/fs/fuse/dev.c +++ b/fs/fuse/dev.c @@ -928,10 +928,14 @@ static int fuse_try_move_page(struct fuse_copy_state *cs, struct page **pagep) folio_test_writeback(oldfolio))) goto out_fallback_unlock; if (WARN_ON(folio_test_mlocked(oldfolio))) goto out_fallback_unlock; + err = lock_request(cs->req); + if (err) + goto out_fallback_unlock; + replace_page_cache_folio(oldfolio, newfolio); folio_get(newfolio); if (!(buf->flags & PIPE_BUF_FLAG_LRU)) @@ -941,24 +945,11 @@ static int fuse_try_move_page(struct fuse_copy_state *cs, struct page **pagep) * Release while we have extra ref on stolen page. Otherwise * anon_pipe_buf_release() might think the page can be reused. */ pipe_buf_release(cs->pipe, buf); - err = 0; - spin_lock(&cs->req->waitq.lock); - if (test_bit(FR_ABORTED, &cs->req->flags)) - err = -ENOENT; - else - *pagep = &newfolio->page; - spin_unlock(&cs->req->waitq.lock); - - if (err) { - folio_unlock(newfolio); - folio_put(newfolio); - goto out_put_old; - } - + *pagep = &newfolio->page; folio_unlock(oldfolio); /* Drop ref for ap->pages[] array */ folio_put(oldfolio); cs->len = 0; -- 2.52.0

1 5

[PATCH openEuler-1.0-LTS] security/keys: fix missed RCU read section on lookup
by Yi Yang 24 Jul '26

24 Jul '26

From: Linus Torvalds <torvalds(a)linux-foundation.org> mainline inclusion from mainline-v7.1-rc6 commit 43a1e3744548e6fd85873e6fb43e293eb4010694 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16340 CVE: CVE-2026-64015 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Nicholas Carlini reports that the keyring code calls assoc_array_find() in find_key_to_update() without holding the RCU read lock, while the assoc_array_gc() code really is designed around removing the node from the tree and then freeing it after an RCU grace-period. The regular key handling doesn't see this because holding the keyring semaphore hides any lifetime issues, but the persistent key handling uses a different model. Instead of extending the keyring locking, just do the simple RCU locking that the assoc_array was designed for. Reported-by: Nicholas Carlini <npc(a)anthropic.com> Cc: David Howells <dhowells(a)redhat.com> Cc: Jarkko Sakkinen <jarkko(a)kernel.org> Cc: Paul Moore <paul(a)paul-moore.com> Cc: James Morris James Morris <jmorris(a)namei.org> Cc: Serge E. Hallyn <serge(a)hallyn.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Conflicts: security/keys/keyring.c [Commit 54da6a092431 ("locking: Introduce __cleanup() based infrastructure") was nor merged. The guard() function was not introduced.] Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- security/keys/keyring.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/security/keys/keyring.c b/security/keys/keyring.c index 0f414a114729..cdaf751811fc 100644 --- a/security/keys/keyring.c +++ b/security/keys/keyring.c @@ -1064,12 +1064,14 @@ key_ref_t find_key_to_update(key_ref_t keyring_ref, kenter("{%d},{%s,%s}", keyring->serial, index_key->type->name, index_key->description); + rcu_read_lock(); object = assoc_array_find(&keyring->keys, &keyring_assoc_array_ops, index_key); if (object) goto found; + rcu_read_unlock(); kleave(" = NULL"); return NULL; @@ -1077,10 +1079,12 @@ key_ref_t find_key_to_update(key_ref_t keyring_ref, key = keyring_ptr_to_key(object); if (key->flags & ((1 << KEY_FLAG_INVALIDATED) | (1 << KEY_FLAG_REVOKED))) { + rcu_read_unlock(); kleave(" = NULL [x]"); return NULL; } __key_get(key); + rcu_read_unlock(); kleave(" = {%d}", key->serial); return make_key_ref(key, is_key_possessed(keyring_ref)); } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS v2] xfs: resample the data fork mapping after cycling ILOCK
by Zizhi Wo 24 Jul '26

24 Jul '26

From: "Darrick J. Wong" <djwong(a)kernel.org> stable inclusion from stable-v6.12.96 commit e705d81a7193dd19e69b8e2bad4696d78a4ea075 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16521 CVE: CVE-2026-64600 Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit… -------------------------------- commit 2f4acd0fcd862e22eab45690ec2c08c80b6ef2e7 upstream. xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle. Cc: hch(a)lst.de Cc: stable(a)vger.kernel.org # v4.11 Fixes: 3c68d44a2b49a0 ("xfs: allocate direct I/O COW blocks in iomap_begin") Signed-off-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Carlos Maiolino <cmaiolino(a)redhat.com> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: fs/xfs/xfs_reflink.c [In this version, the logic of xfs_reflink_fill_cow_hole/delalloc is all contained within xfs_reflink_allocate_cow(), adapt it directly.] Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/xfs/xfs_reflink.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c index 6622652a85a8..c0f5990b4a9f 100644 --- a/fs/xfs/xfs_reflink.c +++ b/fs/xfs/xfs_reflink.c @@ -404,10 +404,11 @@ xfs_reflink_allocate_cow( { struct xfs_mount *mp = ip->i_mount; xfs_fileoff_t offset_fsb = imap->br_startoff; xfs_filblks_t count_fsb = imap->br_blockcount; struct xfs_trans *tp; + unsigned int seq_before = READ_ONCE(ip->i_df.if_seq); int nimaps, error = 0; bool found; xfs_filblks_t resaligned; xfs_extlen_t resblks = 0; @@ -434,10 +435,26 @@ xfs_reflink_allocate_cow( error = xfs_qm_dqattach_locked(ip, false); if (error) goto out_trans_cancel; + /* + * The data fork mapping may have changed while we dropped the ILOCK + * (a racing O_DIRECT writer under IOLOCK_SHARED can complete a full + * CoW cycle including xfs_reflink_end_cow(), which remaps this offset + * and drops the refcount of the old shared block). Re-read it so the + * shared-status recheck below and the caller's in-place iomap both + * operate on the current mapping rather than a stale physical block. + */ + if (seq_before != READ_ONCE(ip->i_df.if_seq)) { + nimaps = 1; + error = xfs_bmapi_read(ip, imap->br_startoff, + imap->br_blockcount, imap, &nimaps, 0); + if (error) + goto out_trans_cancel; + } + /* * Check for an overlapping extent again now that we dropped the ilock. */ error = xfs_find_trim_cow_extent(ip, imap, shared, &found); if (error || !*shared) -- 2.52.0

2 1

[PATCH OLK-5.10] xfs: resample the data fork mapping after cycling ILOCK
by Zizhi Wo 24 Jul '26

24 Jul '26

From: "Darrick J. Wong" <djwong(a)kernel.org> stable inclusion from stable-v6.12.96 commit e705d81a7193dd19e69b8e2bad4696d78a4ea075 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16521 CVE: CVE-2026-64600 Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit… -------------------------------- commit 2f4acd0fcd862e22eab45690ec2c08c80b6ef2e7 upstream. xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle. Cc: hch(a)lst.de Cc: stable(a)vger.kernel.org # v4.11 Fixes: 3c68d44a2b49a0 ("xfs: allocate direct I/O COW blocks in iomap_begin") Signed-off-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Carlos Maiolino <cmaiolino(a)redhat.com> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: fs/xfs/xfs_reflink.c [In this version, the logic of xfs_reflink_fill_cow_hole/delalloc is all contained within xfs_reflink_allocate_cow(), adapt it directly.] Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/xfs/xfs_reflink.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c index 551cc92b049d..6ff06c7ab5e6 100644 --- a/fs/xfs/xfs_reflink.c +++ b/fs/xfs/xfs_reflink.c @@ -352,10 +352,11 @@ xfs_reflink_allocate_cow( { struct xfs_mount *mp = ip->i_mount; xfs_fileoff_t offset_fsb = imap->br_startoff; xfs_filblks_t count_fsb = imap->br_blockcount; struct xfs_trans *tp; + unsigned int seq_before = READ_ONCE(ip->i_df.if_seq); int nimaps, error = 0; bool found; xfs_filblks_t resaligned; xfs_extlen_t resblks = 0; @@ -383,10 +384,26 @@ xfs_reflink_allocate_cow( if (error) return error; *lockmode = XFS_ILOCK_EXCL; + /* + * The data fork mapping may have changed while we dropped the ILOCK + * (a racing O_DIRECT writer under IOLOCK_SHARED can complete a full + * CoW cycle including xfs_reflink_end_cow(), which remaps this offset + * and drops the refcount of the old shared block). Re-read it so the + * shared-status recheck below and the caller's in-place iomap both + * operate on the current mapping rather than a stale physical block. + */ + if (seq_before != READ_ONCE(ip->i_df.if_seq)) { + nimaps = 1; + error = xfs_bmapi_read(ip, imap->br_startoff, + imap->br_blockcount, imap, &nimaps, 0); + if (error) + goto out_trans_cancel; + } + /* * Check for an overlapping extent again now that we dropped the ilock. */ error = xfs_find_trim_cow_extent(ip, imap, cmap, shared, &found); if (error || !*shared) -- 2.52.0

2 1

[PATCH OLK-6.6] xfs: resample the data fork mapping after cycling ILOCK
by Zizhi Wo 24 Jul '26

24 Jul '26

From: "Darrick J. Wong" <djwong(a)kernel.org> stable inclusion from stable-v6.12.96 commit e705d81a7193dd19e69b8e2bad4696d78a4ea075 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16521 CVE: CVE-2026-64600 Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit… -------------------------------- commit 2f4acd0fcd862e22eab45690ec2c08c80b6ef2e7 upstream. xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle. Cc: hch(a)lst.de Cc: stable(a)vger.kernel.org # v4.11 Fixes: 3c68d44a2b49a0 ("xfs: allocate direct I/O COW blocks in iomap_begin") Signed-off-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Carlos Maiolino <cmaiolino(a)redhat.com> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/xfs/xfs_reflink.c | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c index 3431d0d8b6f3..4b598e6841c2 100644 --- a/fs/xfs/xfs_reflink.c +++ b/fs/xfs/xfs_reflink.c @@ -387,10 +387,11 @@ xfs_reflink_fill_cow_hole( { struct xfs_mount *mp = ip->i_mount; struct xfs_trans *tp; xfs_filblks_t resaligned; xfs_extlen_t resblks; + unsigned int seq_before = READ_ONCE(ip->i_df.if_seq); int nimaps; int error; bool found; resaligned = xfs_aligned_fsb_count(imap->br_startoff, @@ -405,10 +406,26 @@ xfs_reflink_fill_cow_hole( if (error) return error; *lockmode = XFS_ILOCK_EXCL; + /* + * The data fork mapping may have changed while we dropped the ILOCK + * (a racing O_DIRECT writer under IOLOCK_SHARED can complete a full + * CoW cycle including xfs_reflink_end_cow(), which remaps this offset + * and drops the refcount of the old shared block). Re-read it so the + * shared-status recheck below and the caller's in-place iomap both + * operate on the current mapping rather than a stale physical block. + */ + if (seq_before != READ_ONCE(ip->i_df.if_seq)) { + nimaps = 1; + error = xfs_bmapi_read(ip, imap->br_startoff, + imap->br_blockcount, imap, &nimaps, 0); + if (error) + goto out_trans_cancel; + } + error = xfs_find_trim_cow_extent(ip, imap, cmap, shared, &found); if (error || !*shared) goto out_trans_cancel; if (found) { @@ -451,20 +468,39 @@ xfs_reflink_fill_delalloc( int nimaps; int error; bool found; do { + unsigned int seq_before = READ_ONCE(ip->i_df.if_seq); + xfs_iunlock(ip, *lockmode); *lockmode = 0; error = xfs_trans_alloc_inode(ip, &M_RES(mp)->tr_write, 0, 0, false, &tp); if (error) return error; *lockmode = XFS_ILOCK_EXCL; + /* + * The data fork mapping may have changed while we dropped the + * ILOCK (a racing O_DIRECT writer under IOLOCK_SHARED can + * complete a full CoW cycle including xfs_reflink_end_cow(), + * which remaps this offset and drops the refcount of the old + * shared block). Re-read it so the shared-status recheck + * below and the caller's in-place iomap both operate on the + * current mapping rather than a stale physical block. + */ + if (seq_before != READ_ONCE(ip->i_df.if_seq)) { + nimaps = 1; + error = xfs_bmapi_read(ip, imap->br_startoff, + imap->br_blockcount, imap, &nimaps, 0); + if (error) + goto out_trans_cancel; + } + error = xfs_find_trim_cow_extent(ip, imap, cmap, shared, &found); if (error || !*shared) goto out_trans_cancel; -- 2.52.0

2 1

[PATCH] [openEuler-1.0-LTS] fuse: re-lock request before replacing page cache folio
by Lu Chentao 24 Jul '26

24 Jul '26

mainline inclusion from mainline-v7.2-rc1 commit a078484921052d0badd827fcc2770b5cfc1d4120 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16108 CVE: CVE-2026-53388 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio(). Fixes: ce534fb05292 ("fuse: allow splice to move pages") Cc: stable(a)vger.kernel.org Reported-by: Lei Lu <llfamsec(a)gmail.com> Signed-off-by: Joanne Koong <joannelkoong(a)gmail.com> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Conflicts: fs/fuse/dev.c [Conflicts due to context] Signed-off-by: Lu Chentao <luchentao1(a)huawei.com> --- fs/fuse/dev.c | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c index bd5293e01e48..6d6bf2e7bb9b 100644 --- a/fs/fuse/dev.c +++ b/fs/fuse/dev.c @@ -897,10 +897,14 @@ static int fuse_try_move_page(struct fuse_copy_state *cs, struct page **pagep) if (WARN_ON(PageDirty(oldpage) || PageWriteback(oldpage))) goto out_fallback_unlock; if (WARN_ON(PageMlocked(oldpage))) goto out_fallback_unlock; + err = lock_request(cs->req); + if (err) + goto out_fallback_unlock; + err = replace_page_cache_page(oldpage, newpage, GFP_KERNEL); if (err) { unlock_page(newpage); goto out_put_old; } @@ -914,24 +918,11 @@ static int fuse_try_move_page(struct fuse_copy_state *cs, struct page **pagep) * Release while we have extra ref on stolen page. Otherwise * anon_pipe_buf_release() might think the page can be reused. */ pipe_buf_release(cs->pipe, buf); - err = 0; - spin_lock(&cs->req->waitq.lock); - if (test_bit(FR_ABORTED, &cs->req->flags)) - err = -ENOENT; - else - *pagep = newpage; - spin_unlock(&cs->req->waitq.lock); - - if (err) { - unlock_page(newpage); - put_page(newpage); - goto out_put_old; - } - + *pagep = newpage; unlock_page(oldpage); /* Drop ref for ap->pages[] array */ put_page(oldpage); cs->len = 0; -- 2.52.0

1 2

[PATCH] [OLK-5.10] fuse: re-lock request before replacing page cache folio
by Lu Chentao 24 Jul '26

24 Jul '26

mainline inclusion from mainline-v7.2-rc1 commit a078484921052d0badd827fcc2770b5cfc1d4120 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16108 CVE: CVE-2026-53388 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio(). Fixes: ce534fb05292 ("fuse: allow splice to move pages") Cc: stable(a)vger.kernel.org Reported-by: Lei Lu <llfamsec(a)gmail.com> Signed-off-by: Joanne Koong <joannelkoong(a)gmail.com> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Conflicts: fs/fuse/dev.c [Conflicts due to context] Signed-off-by: Lu Chentao <luchentao1(a)huawei.com> --- fs/fuse/dev.c | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c index 0c4487e4b867..1a12515fd8ea 100644 --- a/fs/fuse/dev.c +++ b/fs/fuse/dev.c @@ -1186,10 +1186,14 @@ static int fuse_try_move_page(struct fuse_copy_state *cs, struct page **pagep) if (WARN_ON(PageDirty(oldpage) || PageWriteback(oldpage))) goto out_fallback_unlock; if (WARN_ON(PageMlocked(oldpage))) goto out_fallback_unlock; + err = lock_request(cs->req); + if (err) + goto out_fallback_unlock; + err = replace_page_cache_page(oldpage, newpage, GFP_KERNEL); if (err) { unlock_page(newpage); goto out_put_old; } @@ -1203,24 +1207,11 @@ static int fuse_try_move_page(struct fuse_copy_state *cs, struct page **pagep) * Release while we have extra ref on stolen page. Otherwise * anon_pipe_buf_release() might think the page can be reused. */ pipe_buf_release(cs->pipe, buf); - err = 0; - spin_lock(&cs->req->waitq.lock); - if (test_bit(FR_ABORTED, &cs->req->flags)) - err = -ENOENT; - else - *pagep = newpage; - spin_unlock(&cs->req->waitq.lock); - - if (err) { - unlock_page(newpage); - put_page(newpage); - goto out_put_old; - } - + *pagep = newpage; unlock_page(oldpage); /* Drop ref for ap->pages[] array */ put_page(oldpage); cs->len = 0; -- 2.52.0

1 2

[PATCH] [OLK-6.6] fuse: re-lock request before replacing page cache folio
by Lu Chentao 24 Jul '26

24 Jul '26

From: Joanne Koong <joannelkoong(a)gmail.com> stable inclusion from stable-v6.6.144 commit 030fe3e9d8abdee303dd7e9e42f45082d382a407 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16108 CVE: CVE-2026-53388 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- [ Upstream commit a078484921052d0badd827fcc2770b5cfc1d4120 ] fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio(). Fixes: ce534fb05292 ("fuse: allow splice to move pages") Cc: stable(a)vger.kernel.org Reported-by: Lei Lu <llfamsec(a)gmail.com> Signed-off-by: Joanne Koong <joannelkoong(a)gmail.com> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lu Chentao <luchentao1(a)huawei.com> --- fs/fuse/dev.c | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c index 75c067522c98..f197909aee8d 100644 --- a/fs/fuse/dev.c +++ b/fs/fuse/dev.c @@ -928,10 +928,14 @@ static int fuse_try_move_page(struct fuse_copy_state *cs, struct page **pagep) folio_test_writeback(oldfolio))) goto out_fallback_unlock; if (WARN_ON(folio_test_mlocked(oldfolio))) goto out_fallback_unlock; + err = lock_request(cs->req); + if (err) + goto out_fallback_unlock; + replace_page_cache_folio(oldfolio, newfolio); folio_get(newfolio); if (!(buf->flags & PIPE_BUF_FLAG_LRU)) @@ -941,24 +945,11 @@ static int fuse_try_move_page(struct fuse_copy_state *cs, struct page **pagep) * Release while we have extra ref on stolen page. Otherwise * anon_pipe_buf_release() might think the page can be reused. */ pipe_buf_release(cs->pipe, buf); - err = 0; - spin_lock(&cs->req->waitq.lock); - if (test_bit(FR_ABORTED, &cs->req->flags)) - err = -ENOENT; - else - *pagep = &newfolio->page; - spin_unlock(&cs->req->waitq.lock); - - if (err) { - folio_unlock(newfolio); - folio_put(newfolio); - goto out_put_old; - } - + *pagep = &newfolio->page; folio_unlock(oldfolio); /* Drop ref for ap->pages[] array */ folio_put(oldfolio); cs->len = 0; -- 2.52.0

1 5

[PATCH openEuler-1.0-LTS v2] xfs: resample the data fork mapping after cycling ILOCK
by Zizhi Wo 24 Jul '26

24 Jul '26

From: "Darrick J. Wong" <djwong(a)kernel.org> stable inclusion from stable-v6.12.96 commit e705d81a7193dd19e69b8e2bad4696d78a4ea075 category: bugfix bugzilla: NA CVE: CVE-2026-64600 Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit… -------------------------------- commit 2f4acd0fcd862e22eab45690ec2c08c80b6ef2e7 upstream. xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle. Cc: hch(a)lst.de Cc: stable(a)vger.kernel.org # v4.11 Fixes: 3c68d44a2b49a0 ("xfs: allocate direct I/O COW blocks in iomap_begin") Signed-off-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Carlos Maiolino <cmaiolino(a)redhat.com> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: fs/xfs/xfs_reflink.c [In this version, the logic of xfs_reflink_fill_cow_hole/delalloc is all contained within xfs_reflink_allocate_cow(), adapt it directly.] Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/xfs/xfs_reflink.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c index 6622652a85a8..c0f5990b4a9f 100644 --- a/fs/xfs/xfs_reflink.c +++ b/fs/xfs/xfs_reflink.c @@ -404,10 +404,11 @@ xfs_reflink_allocate_cow( { struct xfs_mount *mp = ip->i_mount; xfs_fileoff_t offset_fsb = imap->br_startoff; xfs_filblks_t count_fsb = imap->br_blockcount; struct xfs_trans *tp; + unsigned int seq_before = READ_ONCE(ip->i_df.if_seq); int nimaps, error = 0; bool found; xfs_filblks_t resaligned; xfs_extlen_t resblks = 0; @@ -434,10 +435,26 @@ xfs_reflink_allocate_cow( error = xfs_qm_dqattach_locked(ip, false); if (error) goto out_trans_cancel; + /* + * The data fork mapping may have changed while we dropped the ILOCK + * (a racing O_DIRECT writer under IOLOCK_SHARED can complete a full + * CoW cycle including xfs_reflink_end_cow(), which remaps this offset + * and drops the refcount of the old shared block). Re-read it so the + * shared-status recheck below and the caller's in-place iomap both + * operate on the current mapping rather than a stale physical block. + */ + if (seq_before != READ_ONCE(ip->i_df.if_seq)) { + nimaps = 1; + error = xfs_bmapi_read(ip, imap->br_startoff, + imap->br_blockcount, imap, &nimaps, 0); + if (error) + goto out_trans_cancel; + } + /* * Check for an overlapping extent again now that we dropped the ilock. */ error = xfs_find_trim_cow_extent(ip, imap, shared, &found); if (error || !*shared) -- 2.52.0

2 1