On Mon 06-08-18 15:59:27, Andrew Morton wrote:I think most of time i_size is within s_maxbytes in local filesystem,
On Mon, 6 Aug 2018 12:22:03 +0200 Jan Kara <jack@xxxxxxx> wrote:So I don't think there's any sanitization going on before
On Fri 20-07-18 16:14:29, Andrew Morton wrote:Sure. But is it possible for userspace to trigger this behaviour?
On Thu, 19 Jul 2018 10:58:12 +0200 Jan Kara <jack@xxxxxxx> wrote:Good question. I think ->readpage() could be called for index beyond
On Thu 19-07-18 16:17:26, Chengguang Xu wrote:Yup.
When we try to truncate read count in generic_file_buffered_read(),Looks good to me. You can add:
should deliver (sb->s_maxbytes - offset) as maximum count not
sb->s_maxbytes itself.
Signed-off-by: Chengguang Xu <cgxu519@xxxxxxx>
Reviewed-by: Jan Kara <jack@xxxxxxx>
What are the runtime effects of this bug?
maximum file size supported by the filesystem leading to weird filesystem
behavior due to overflows in internal calculations.
Possibly all callers have already sanitized the arguments by this stage
in which case the statement is arguably redundant.
generic_file_buffered_read(). E.g. I don't see any s_maxbytes check on
ksys_read() -> vfs_read() -> __vfs_read() -> new_sync_read() ->
call_read_iter() -> generic_file_read_iter() ->
generic_file_buffered_read() path... However now thinking about this again:
We are guaranteed i_size is within s_maxbytes (places modifying i_size
are checking for this) and generic_file_buffered_read() stops when it
should read beyond i_size. So in the end I don't think there's any breakage
possible and the patch is not necessary?