linux-kernel - Re: [PATCH 2/4] configfs: Fix writing at a non-zero offset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 26 Jul 2021 16:58:13 +0200
From:   Bodo Stroesser <bostroesser@...il.com>
To:     Bart Van Assche <bvanassche@....org>,
        Christoph Hellwig <hch@....de>
Cc:     Joel Becker <jlbec@...lplan.org>, linux-kernel@...r.kernel.org,
        "Martin K . Petersen" <martin.petersen@...cle.com>,
        Yanko Kaneti <yaneti@...lera.com>,
        Brendan Higgins <brendanhiggins@...gle.com>
Subject: Re: [PATCH 2/4] configfs: Fix writing at a non-zero offset

On 23.07.21 23:23, Bart Van Assche wrote:
> Store data at the right offset when writing with a non-zero offset. I think
> this patch fixes behavior introduced in the initial configfs commit.

Unfortunately I think it does not.

Let's say user writes 5 times to configfs file while keeping it open.
On every write() call it writes 1 character only, e.g. first "A", then "B", ...

The original code before the changes 5 times called flush_write_buffer for the
strings "A\0", "B\0", ... (with the '\0' not included in the count parameter,
so count is 1 always, which is the length of the last write).

Since commit
     420405ecde06  "configfs: fix the read and write iterators"
flush_write_buffer is called for the strings "A\0", "AB\0", "ABC\0", ...
but count still is 1.

This fix changes just the count parameter, so it now is 1, 2, 3, ... in our
example. But it still sends on every call to flush_write_buffer all the write
data gathered since last open().

I think, a simple way to restore the original behavior would be to revert the
part of commit 420405ecde06 that changed write routines.

Bodo

 From a
> source code comment in the initial configfs commit: "There is no easy way
> for us to know if userspace is only doing a partial write, so we don't
> support them."
> 
> Cc: Bodo Stroesser <bostroesser@...il.com>
> Cc: Martin K. Petersen <martin.petersen@...cle.com>
> Cc: Yanko Kaneti <yaneti@...lera.com>
> Cc: Brendan Higgins <brendanhiggins@...gle.com>
> Signed-off-by: Bart Van Assche <bvanassche@....org>
> ---
>   fs/configfs/file.c | 10 ++++++----
>   1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/configfs/file.c b/fs/configfs/file.c
> index 8121bb1b2121..3b2ddc2e5d42 100644
> --- a/fs/configfs/file.c
> +++ b/fs/configfs/file.c
> @@ -226,14 +226,16 @@ static ssize_t configfs_write_iter(struct kiocb *iocb, struct iov_iter *from)
>   {
>   	struct file *file = iocb->ki_filp;
>   	struct configfs_buffer *buffer = file->private_data;
> -	ssize_t len;
> +	int len, written = 0;
>   
>   	mutex_lock(&buffer->mutex);
>   	len = fill_write_buffer(buffer, iocb->ki_pos, from);
>   	if (len > 0)
> -		len = flush_write_buffer(file, buffer, len);
> -	if (len > 0)
> -		iocb->ki_pos += len;
> +		written = flush_write_buffer(file, buffer, iocb->ki_pos + len);
> +	if (written > 0) {
> +		len = max_t(int, 0, written - iocb->ki_pos);
> +		iocb->ki_pos = written;
> +	}
>   	mutex_unlock(&buffer->mutex);
>   	return len;
>   }
>