From fb06c65ee90e31d11cf37b3469f7d3336ae51184 Mon Sep 17 00:00:00 2001 From: Jakob Unterwurzacher Date: Sun, 1 Apr 2018 21:21:55 +0200 Subject: [PATCH] fusefronted: reject oversized Read and Write requests This should not happen via FUSE as the kernel caps the size, but with fsck we have the first user that calls Read directly. For symmetry, check it for Write as well. --- internal/fusefrontend/file.go | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/internal/fusefrontend/file.go b/internal/fusefrontend/file.go index f765eae..e1ce6a9 100644 --- a/internal/fusefrontend/file.go +++ b/internal/fusefrontend/file.go @@ -228,6 +228,12 @@ func (f *file) doRead(dst []byte, off uint64, length uint64) ([]byte, fuse.Statu // Read - FUSE call func (f *file) Read(buf []byte, off int64) (resultData fuse.ReadResult, code fuse.Status) { + if len(buf) > fuse.MAX_KERNEL_WRITE { + // This would crash us due to our fixed-size buffer pool + tlog.Warn.Printf("Read: rejecting oversized request with EMSGSIZE, len=%d", len(buf)) + return nil, fuse.Status(syscall.EMSGSIZE) + } + f.fdLock.RLock() defer f.fdLock.RUnlock() @@ -346,6 +352,11 @@ func (f *file) isConsecutiveWrite(off int64) bool { // // If the write creates a hole, pads the file to the next block boundary. func (f *file) Write(data []byte, off int64) (uint32, fuse.Status) { + if len(data) > fuse.MAX_KERNEL_WRITE { + // This would crash us due to our fixed-size buffer pool + tlog.Warn.Printf("Write: rejecting oversized request with EMSGSIZE, len=%d", len(data)) + return 0, fuse.Status(syscall.EMSGSIZE) + } f.fdLock.RLock() defer f.fdLock.RUnlock() if f.released {