From: Tyler Hicks <code@tyhicks.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christian Brauner <brauner@kernel.org>,
linux-kernel@vger.kernel.org, ecryptfs@vger.kernel.org
Subject: [GIT PULL] eCryptfs fixes for 7.3-rc1
Date: Thu, 20 Aug 2026 19:22:55 -0500 [thread overview]
Message-ID: <aoeaX-Z7eSZuYP1A@elm> (raw)
Hi Linus,
The following changes since commit a13c140cc289c0b7b3770bce5b3ad42ab35074aa:
Linux 7.2-rc3 (2026-07-12 14:16:39 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs.git tags/ecryptfs-7.3-rc1
for you to fetch changes up to f81cb44f9a4b88d73ee5dec4a1ccdb0232fd2e3f:
ecryptfs: ecryptfs_kernel.h: clean up kernel-doc comments (2026-07-22 19:59:33 -0500)
----------------------------------------------------------------
eCryptfs updates for 7.3-rc1
The set of eCryptfs changes for the 7.3-rc1 merge window consists of:
- Hardening and fixes for maliciously crafted eCryptfs metadata in the
lower encrypted file
- Hardening and fixes for maliciously crafted userspace <-> kernel
miscdev communications
- Locking fixes for userspace <-> kernel miscdev communications
- Fix to display encrypted filename related mount options
- Clean up address_space_operations and reduce build dependencies by
moving to filemap_dirty_folio()
- Get rid of an unnecessary memory allocation in the inode update path
- Kernel-doc formatting corrections
The patches have all spent time in linux-next and they pass all tests in
the ecryptfs-utils tree. I did manual validation of the miscdev fixes
since we don't have test coverage for that feature.
----------------------------------------------------------------
Aditya Prakash Srivastava (1):
ecryptfs: use filemap_dirty_folio for address space operations
HanQuan (1):
ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet
Pengpeng Hou (1):
eCryptfs: bound the packet-length peek to the user buffer
Randy Dunlap (1):
ecryptfs: ecryptfs_kernel.h: clean up kernel-doc comments
Yichong Chen (7):
ecryptfs: release message context on send failure
ecryptfs: hold msg ctx list lock when cleaning daemon queue
ecryptfs: pass packet set buffer size to parser
ecryptfs: fix tag 11 packet exact-fit size check
ecryptfs: reject too-small tag 70 packets
ecryptfs: show filename encryption options
ecryptfs: avoid heap allocation for inode size write
fs/ecryptfs/crypto.c | 2 +-
fs/ecryptfs/ecryptfs_kernel.h | 15 ++++++++-------
fs/ecryptfs/keystore.c | 45 +++++++++++++++++++++++++++++++++++++------
fs/ecryptfs/messaging.c | 11 ++++++++++-
fs/ecryptfs/miscdev.c | 5 +++--
fs/ecryptfs/mmap.c | 30 +++++------------------------
fs/ecryptfs/super.c | 7 +++++++
7 files changed, 73 insertions(+), 42 deletions(-)
reply other threads:[~2026-08-21 0:23 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=aoeaX-Z7eSZuYP1A@elm \
--to=code@tyhicks.com \
--cc=brauner@kernel.org \
--cc=ecryptfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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.