EcryptFS development
 help / color / mirror / Atom feed
From: Tyler Hicks <code@tyhicks.com>
To: Pengpeng Hou <pengpeng@iscas.ac.cn>
Cc: ecryptfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	Michael Halcrow <mhalcrow@us.ibm.com>
Subject: Re: [PATCH] ecryptfs: validate encoded packet length extent
Date: Thu, 16 Jul 2026 10:12:20 -0500	[thread overview]
Message-ID: <alj01DBcUTGaE5DO@elm> (raw)
In-Reply-To: <20260715083702.29471-1-pengpeng@iscas.ac.cn>

On 2026-07-15 16:37:02, Pengpeng Hou wrote:
> ecryptfs_miscdev_write() accepts a six-byte write as a minimally sized
> message.  It then copies two bytes from the packet-length field at byte
> offset five, although such an input supplies only the first byte.
> 
> Copy only the bytes covered by the current write.  When the first byte
> selects the two-byte encoding, reject the message unless it also supplies
> the second byte before calling ecryptfs_parse_packet_length().
> 
> Fixes: 8bf2debd5f7b ("eCryptfs: introduce device handle for userspace daemon communications")
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>

Hello and thank you for the fix! Some comments below...

> ---
>  fs/ecryptfs/miscdev.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/ecryptfs/miscdev.c b/fs/ecryptfs/miscdev.c
> index 5a7d08149922..a99e16db8243 100644
> --- a/fs/ecryptfs/miscdev.c
> +++ b/fs/ecryptfs/miscdev.c
> @@ -360,7 +360,7 @@ ecryptfs_miscdev_write(struct file *file, const char __user *buf,
>  	u32 seq;
>  	size_t packet_size, packet_size_length;
>  	char *data;
> -	unsigned char packet_size_peek[ECRYPTFS_MAX_PKT_LEN_SIZE];
> +	unsigned char packet_size_peek[ECRYPTFS_MAX_PKT_LEN_SIZE] = { 0 };
>  	ssize_t rc;
>  
>  	if (count == 0) {
> @@ -376,11 +376,17 @@ ecryptfs_miscdev_write(struct file *file, const char __user *buf,
>  	}
>  
>  	if (copy_from_user(packet_size_peek, &buf[PKT_LEN_OFFSET],
> -			   sizeof(packet_size_peek))) {
> +			   min_t(size_t, count - PKT_LEN_OFFSET,
> +				 sizeof(packet_size_peek)))) {

This is a good change and fixes a potential one-byte over read.

>  		printk(KERN_WARNING "%s: Error while inspecting packet size\n",
>  		       __func__);
>  		return -EFAULT;
>  	}
> +	if (packet_size_peek[0] >= 192 && packet_size_peek[0] < 224 &&
> +	    count - PKT_LEN_OFFSET < ECRYPTFS_MAX_PKT_LEN_SIZE) {
> +		ecryptfs_printk(KERN_WARNING, "Truncated packet length\n");
> +		return -EINVAL;
> +	}

I don't think that this new check is necessary. The call to
ecryptfs_parse_packet_length(), below, will already return a
packet_size_length of 2 if packet_size_peek[0] is >= 192.

The existing check, right after the call to
ecryptfs_parse_packet_length() is error checked, ensures that the value
of count is equal to 1 + 4 + 2 + packet_size. This already protects
against the truncated packet length issue that the new conditional is
checking. Do you agree?

Tyler

>  
>  	rc = ecryptfs_parse_packet_length(packet_size_peek, &packet_size,
>  					  &packet_size_length);
> -- 
> 2.43.0
> 

      reply	other threads:[~2026-07-16 15:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15  8:37 [PATCH] ecryptfs: validate encoded packet length extent Pengpeng Hou
2026-07-16 15:12 ` Tyler Hicks [this message]

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=alj01DBcUTGaE5DO@elm \
    --to=code@tyhicks.com \
    --cc=ecryptfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhalcrow@us.ibm.com \
    --cc=pengpeng@iscas.ac.cn \
    /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