From: <gregkh@linuxfoundation.org>
To: mason@kernel.org,amir73il@gmail.com
Cc: <stable@vger.kernel.org>
Subject: FAILED: patch "[PATCH] ovl: always encode the origin fh when index is enabled" failed to apply to 6.6-stable tree
Date: Wed, 04 Nov 2026 15:35:44 +0100 [thread overview]
Message-ID: <2026110444-paralysis-cement-a86c@gregkh> (raw)
The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y
git checkout FETCH_HEAD
git cherry-pick -x 949f9d8a5580c77a45fa759123367682aba4d173
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026110444-paralysis-cement-a86c@gregkh' --subject-prefix 'PATCH 6.6.y' 'HEAD^..'
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 949f9d8a5580c77a45fa759123367682aba4d173 Mon Sep 17 00:00:00 2001
From: Chris Mason <mason@kernel.org>
Date: Fri, 16 Oct 2026 21:17:07 +0000
Subject: [PATCH] ovl: always encode the origin fh when index is enabled
On an overlay with index=on,nfs_export=on, copy up of a directory
crashes the kernel once an LSM has started to deny CAP_DAC_READ_SEARCH
to the mounter, the task that mounted the overlay. The mount and the LSM
policy change require root. After that, any user who can write to a
directory that exists only in a lower layer triggers the oops by doing
so.
Before a file or directory that exists only in a lower layer is changed
for the first time, overlayfs copies it to the writable upper layer.
This is called copy up.
On copy up, ovl_get_origin_fh() encodes the file handle of the lower
inode, called the origin. It returns NULL if ovl_can_decode_fh() says
that the lower filesystem cannot decode handles. Whether the callers can
handle NULL depends on the index option:
- Without an index, NULL is fine: the callers store an empty origin
xattr.
- With index enabled, overlayfs keeps entries for copied up inodes in an
internal index directory. The name of an index entry is derived from
the handle, so ovl_get_origin_fh() must return a handle or an error.
The mount only enables the index if ovl_can_decode_fh() succeeds for all
layers, but the result can change later. The function checks the export
operations of the filesystem and capable(CAP_DAC_READ_SEARCH). Copy up
runs with the mounter's credentials, and an LSM can start to deny the
capability to those credentials after the mount. ovl_get_origin_fh()
then returns NULL with index enabled.
This goes wrong in two callers:
- With nfs_export=on, copy up of a directory creates an index entry for
the directory. ovl_create_index() passes the NULL handle to
ovl_get_index_name_fh(), which dereferences it.
- If the result changes while mount(2) is still running,
ovl_get_indexdir() passes a NULL from ovl_get_origin_fh() to
ovl_verify_set_fh() in the same way.
Before the commit in the Fixes tag, these two callers encoded the handle
themselves, without consulting ovl_can_decode_fh().
Reproduced with a BPF LSM program that started to deny the capability
after the mount. An unprivileged touch in a directory that had not been
copied up yet oopsed in ovl_get_index_name_fh(). With this patch the
touch succeeds and the directory gets its index entry.
Fix this by calling ovl_can_decode_fh() in ovl_get_origin_fh() only when
index is disabled.
Fixes: 5b02bfc1e7e3 ("ovl: do not encode lower fh with upper sb_writers held")
Cc: stable@vger.kernel.org
Signed-off-by: Chris Mason <mason@kernel.org>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
index 0cd76ca5b8d7..c147ad155b79 100644
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -474,8 +474,12 @@ struct ovl_fh *ovl_get_origin_fh(struct ovl_fs *ofs, struct dentry *origin)
* When lower layer doesn't support export operations store a 'null' fh,
* so we can use the overlay.origin xattr to distignuish between a copy
* up and a pure upper inode.
+ *
+ * With index enabled, mount already found that all layers can decode
+ * file handles. Do not ask again, because an LSM may change its answer
+ * about CAP_DAC_READ_SEARCH and index users cannot cope with a 'null' fh.
*/
- if (!ovl_can_decode_fh(origin->d_sb))
+ if (!ofs->config.index && !ovl_can_decode_fh(origin->d_sb))
return NULL;
return ovl_encode_real_fh(ofs, d_inode(origin), false);
reply other threads:[~2026-11-04 14:35 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026110444-paralysis-cement-a86c@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=amir73il@gmail.com \
--cc=mason@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox