2022-06-25 11:02:44

by Jason A. Donenfeld

[permalink] [raw]
Subject: [PATCH v2 1/8] ksmbd: use vfs_llseek instead of dereferencing NULL

By not checking whether llseek is NULL, this might jump to NULL. Also,
it doesn't check FMODE_LSEEK. Fix this by using vfs_llseek(), which
always does the right thing.

Fixes: f44158485826 ("cifsd: add file operations")
Cc: [email protected]
Cc: [email protected]
Cc: Steve French <[email protected]>
Cc: Ronnie Sahlberg <[email protected]>
Cc: Hyunchul Lee <[email protected]>
Cc: Sergey Senozhatsky <[email protected]>
Reviewed-by: Namjae Jeon <[email protected]>
Acked-by: Al Viro <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>
---
fs/ksmbd/vfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ksmbd/vfs.c b/fs/ksmbd/vfs.c
index dcdd07c6efff..9cf2e2365832 100644
--- a/fs/ksmbd/vfs.c
+++ b/fs/ksmbd/vfs.c
@@ -1046,7 +1046,7 @@ int ksmbd_vfs_fqar_lseek(struct ksmbd_file *fp, loff_t start, loff_t length,
*out_count = 0;
end = start + length;
while (start < end && *out_count < in_count) {
- extent_start = f->f_op->llseek(f, start, SEEK_DATA);
+ extent_start = vfs_llseek(f, start, SEEK_DATA);
if (extent_start < 0) {
if (extent_start != -ENXIO)
ret = (int)extent_start;
@@ -1056,7 +1056,7 @@ int ksmbd_vfs_fqar_lseek(struct ksmbd_file *fp, loff_t start, loff_t length,
if (extent_start >= end)
break;

- extent_end = f->f_op->llseek(f, extent_start, SEEK_HOLE);
+ extent_end = vfs_llseek(f, extent_start, SEEK_HOLE);
if (extent_end < 0) {
if (extent_end != -ENXIO)
ret = (int)extent_end;
--
2.35.1


2022-06-25 22:37:22

by Jason A. Donenfeld

[permalink] [raw]
Subject: Re: [PATCH v2 1/8] ksmbd: use vfs_llseek instead of dereferencing NULL

Hi Steve,

On Sat, Jun 25, 2022 at 01:01:08PM +0200, Jason A. Donenfeld wrote:
> By not checking whether llseek is NULL, this might jump to NULL. Also,
> it doesn't check FMODE_LSEEK. Fix this by using vfs_llseek(), which
> always does the right thing.
>
> Fixes: f44158485826 ("cifsd: add file operations")
> Cc: [email protected]
> Cc: [email protected]
> Cc: Steve French <[email protected]>
> Cc: Ronnie Sahlberg <[email protected]>
> Cc: Hyunchul Lee <[email protected]>
> Cc: Sergey Senozhatsky <[email protected]>
> Reviewed-by: Namjae Jeon <[email protected]>
> Acked-by: Al Viro <[email protected]>
> Signed-off-by: Jason A. Donenfeld <[email protected]>

This commit has been reviewed by Namjae and acked by Al. The rest of the
commits in this series are likely -next material for Al to take in his
vfs tree, but this first one here is something you might consider taking
as a somewhat important bug fix for 5.19. I marked it for stable@ and
such as well. Your call -- you can punt it to Al's -next branch with the
rest of the series if you want -- but I think this patch is a bit unlike
the others. This occurred to me when I saw you sent some cifs fixes in
earlier this evening.

Jason

2022-06-26 01:25:29

by Steve French

[permalink] [raw]
Subject: Re: [PATCH v2 1/8] ksmbd: use vfs_llseek instead of dereferencing NULL

I just added it to ksmbd-for-next

Thx.

On Sat, Jun 25, 2022 at 5:20 PM Jason A. Donenfeld <[email protected]> wrote:
>
> Hi Steve,
>
> On Sat, Jun 25, 2022 at 01:01:08PM +0200, Jason A. Donenfeld wrote:
> > By not checking whether llseek is NULL, this might jump to NULL. Also,
> > it doesn't check FMODE_LSEEK. Fix this by using vfs_llseek(), which
> > always does the right thing.
> >
> > Fixes: f44158485826 ("cifsd: add file operations")
> > Cc: [email protected]
> > Cc: [email protected]
> > Cc: Steve French <[email protected]>
> > Cc: Ronnie Sahlberg <[email protected]>
> > Cc: Hyunchul Lee <[email protected]>
> > Cc: Sergey Senozhatsky <[email protected]>
> > Reviewed-by: Namjae Jeon <[email protected]>
> > Acked-by: Al Viro <[email protected]>
> > Signed-off-by: Jason A. Donenfeld <[email protected]>
>
> This commit has been reviewed by Namjae and acked by Al. The rest of the
> commits in this series are likely -next material for Al to take in his
> vfs tree, but this first one here is something you might consider taking
> as a somewhat important bug fix for 5.19. I marked it for stable@ and
> such as well. Your call -- you can punt it to Al's -next branch with the
> rest of the series if you want -- but I think this patch is a bit unlike
> the others. This occurred to me when I saw you sent some cifs fixes in
> earlier this evening.
>
> Jason



--
Thanks,

Steve