Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix: fix a potential out of bounds issue in fuse #6847

Merged
merged 1 commit into from
Jan 29, 2020
Merged

fix: fix a potential out of bounds issue in fuse #6847

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 6 additions & 11 deletions fuse/readonly/readonly_unix.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -257,13 +257,15 @@ func (s *Node) Read(ctx context.Context, req *fuse.ReadRequest, resp *fuse.ReadR
if err != nil {
return err
}

buf := resp.Data[:min(req.Size, int(int64(r.Size())-req.Offset))]
// Data has a capacity of Size
buf := resp.Data[:int(req.Size)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the out of bounds error that this is fixing? If the issue was that buf could be empty then we still get the error.

Have we introduced another possible out of bounds error here if the response data is less than the request size? Is it really safe to remove the min check here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fuse library gives us a Data buffer a capacity of Size. I believe the issue was that Size()` reported an incorrect size (-1, 0, etc.).

Copy link
Contributor

@aschmahmann aschmahmann Jan 28, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could be wrong here, but I don't think the issue was calculating buf := resp.Data[-1] because that would throw an invalid slice index instead of the index out of range error that was reported in the issue. If so then the panic was caused by the index being too large not too small, and therefore this fix likely won't resolve the issue.

Also, is it possible that req.Size is bigger than the buffer and so we'll run into an out of bounds error with this change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, it should be impossible:

https://github.com/bazil/fuse/blob/7b5117fecadc6b83a347f794d6b8c4bbd0ece881/fs/serve.go#L1185-L1249

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But you're right, -1 would give us a different error. The only sane answer is that Size is too big.

n, err := io.ReadFull(r, buf)
if err != nil && err != io.EOF {
resp.Data = buf[:n]
switch err {
case nil, io.EOF, io.ErrUnexpectedEOF:
default:
return err
}
resp.Data = resp.Data[:n]
lm["res_size"] = n
return nil // may be non-nil / not succeeded
}
Expand All @@ -287,10 +289,3 @@ type roNode interface {
}

var _ roNode = (*Node)(nil)

func min(a, b int) int {
if a < b {
return a
}
return b
}