From: Sam Edwards <cfsworks@gmail.com>
To: Ilya Dryomov <idryomov@gmail.com>,
Alex Markuze <amarkuze@redhat.com>,
Viacheslav Dubeyko <slava@dubeyko.com>
Cc: Jeff Layton <jlayton@kernel.org>, Xiubo Li <xiubli@redhat.com>,
ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
Sam Edwards <CFSworks@gmail.com>
Subject: [PATCH v2 0/2] Bounce buffer for mds client decryption when vmalloc()
Date: Fri, 29 May 2026 20:06:44 -0700 [thread overview]
Message-ID: <20260530030646.85589-1-CFSworks@gmail.com> (raw)
Hi Ceph maintainers,
This is version 2 of my previous patchset to resolve fscrypt oops/panic when
decrypting filenames from a MDS message that spilled into the vmalloc area. [1]
Cheers,
Sam
Changes v1->v2:
- As Slava pointed out, v1 was performing `snprintf(..., oname->name)` *before*
the memcpy() that makes `oname->name` valid. He also raised a great point
about the if/else-if block's complexity. This version simplifies the control
flow structure.
- Reformat some whitespace and remove unnecessary linebreaks, going a little
over the 80-column soft limit, but improving readability.
Feedback not addressed:
- David shared some discomfort about fscrypt_fname_alloc_buffer() sometimes
changing the allocation length, but it only ever lengthens the allocation and
is therefore always at least NAME_MAX.
- David also began some discussion around passing an explicit `tname` length;
I'm still open to the idea, but would like to get a consensus around that
first, because enforcing the buffer size will likely require changes to the
base64_{de,en}code() function prototypes to accept buffer sizes.
[1] https://lore.kernel.org/ceph-devel/20260527025828.5966-1-CFSworks@gmail.com/
Sam Edwards (2):
ceph: pass fscrypt `tname` buffers directly
ceph: properly decrypt filenames in vmalloc() buffers
fs/ceph/crypto.c | 50 ++++++++++++++++++++++++++++++++------------
fs/ceph/crypto.h | 4 ++--
fs/ceph/mds_client.c | 12 +++++++----
3 files changed, 47 insertions(+), 19 deletions(-)
--
2.53.0
next reply other threads:[~2026-05-30 3:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-30 3:06 Sam Edwards [this message]
2026-05-30 3:06 ` [PATCH v2 1/2] ceph: pass fscrypt `tname` buffers directly Sam Edwards
2026-05-30 3:06 ` [PATCH v2 2/2] ceph: properly decrypt filenames in vmalloc() buffers Sam Edwards
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=20260530030646.85589-1-CFSworks@gmail.com \
--to=cfsworks@gmail.com \
--cc=amarkuze@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.com \
--cc=jlayton@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=slava@dubeyko.com \
--cc=xiubli@redhat.com \
/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.