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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.