linux-kernel - Re: [PATCH] cifs: Fix unbuffered read

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]

Message-ID: <03d46708ca8adaf2fe98689e04c98541.pc@manguebit.com>
Date:   Tue, 18 Apr 2023 23:16:45 -0300
From:   Paulo Alcantara <pc@...guebit.com>
To:     David Howells <dhowells@...hat.com>,
        Steve French <smfrench@...il.com>
Cc:     dhowells@...hat.com,
        Jérôme Glisse <jglisse@...hat.com>,
        Long Li <longli@...rosoft.com>,
        Enzo Matsumiya <ematsumiya@...e.de>,
        Shyam Prasad N <nspmangalore@...il.com>,
        Rohith Surabattula <rohiths.msft@...il.com>,
        Jeff Layton <jlayton@...nel.org>, linux-cifs@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cifs: Fix unbuffered read

David Howells <dhowells@...hat.com> writes:

> If read() is done in an unbuffered manner, such that, say,
> cifs_strict_readv() goes through cifs_user_readv() and thence
> __cifs_readv(), it doesn't recognise the EOF and keeps indicating to
> userspace that it returning full buffers of data.
>
> This is due to ctx->iter being advanced in cifs_send_async_read() as the
> buffer is split up amongst a number of rdata objects.  The iterator count
> is then used in collect_uncached_read_data() in the non-DIO case to set the
> total length read - and thus the return value of sys_read().  But since the
> iterator normally gets used up completely during splitting, ctx->total_len
> gets overridden to the full amount.
>
> However, prior to that in collect_uncached_read_data(), we've gone through
> the list of rdatas and added up the amount of data we actually received
> (which we then throw away).
>
> Fix this by removing the bit that overrides the amount read in the non-DIO
> case and just going with the total added up in the aforementioned loop.
>
> This was observed by mounting a cifs share with multiple channels, e.g.:
>
> 	mount //192.168.6.1/test /test/ -o user=shares,pass=...,max_channels=6
>
> and then reading a 1MiB file on the share:
>
> 	strace cat /xfstest.test/1M  >/dev/null
>
> Through strace, the same data can be seen being read again and again.
>     
> Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list")
> Signed-off-by: David Howells <dhowells@...hat.com>
> cc: Steve French <smfrench@...il.com>
> cc: Paulo Alcantara <pc@...guebit.com>
> cc: Jérôme Glisse <jglisse@...hat.com>
> cc: Long Li <longli@...rosoft.com>
> cc: Enzo Matsumiya <ematsumiya@...e.de>
> cc: Shyam Prasad N <nspmangalore@...il.com>
> cc: Rohith Surabattula <rohiths.msft@...il.com>
> cc: Jeff Layton <jlayton@...nel.org>
> cc: linux-cifs@...r.kernel.org
> ---
>  fs/cifs/file.c |    4 ----
>  1 file changed, 4 deletions(-)

Acked-by: Paulo Alcantara (SUSE) <pc@...guebit.com>