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:   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>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ