Bug 1071726 - (CVE-2017-15121) VUL-0: CVE-2017-15121: kernel: vfs: BUG in truncate_inode_pages_range() can be triggered by local user
VUL-0: CVE-2017-15121: kernel: vfs: BUG in truncate_inode_pages_range() can b...
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Security Team bot
Security Team bot
Depends on:
  Show dependency treegraph
Reported: 2017-12-07 11:27 UTC by Johannes Segitz
Modified: 2020-06-15 13:27 UTC (History)
7 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Segitz 2017-12-07 11:27:57 UTC

A non-privileged user is able to mount a fuse filesystem on RHEL 6 or 7 and
crash a system if an application punches a hole in a file that does not end
aligned to a page boundary.

Fixed by 5a7203947a1d, < SLE 12 affected

Comment 1 Michal Hocko 2017-12-07 14:06:40 UTC
So the question is, do we allow to mount untrusted filesystem via fuse in SLES? That would certainly sound scary to me. There are countless corner cases in malformed FS.

5a7203947a1d looks like something for Jack
Comment 2 Jan Kara 2017-12-07 14:39:39 UTC
I'm scratching my head how truncate_inode_pages_range() connects with FUSE. It is not calling it (at least not in our code base)... We could call it with end != -1 from ext4 (but that's unsupported in SLE11 codebase), ocfs2 (may be problematic), btrfs (that does its rounding so it does not expose the problem), and ceph (again properly rounded).

So we might need to backport that fix but not because of FUSE...
Comment 3 Jan Kara 2017-12-15 10:17:14 UTC
OK, after some more digging ext4 properly rounds arguments to truncate_inode_pages_range() so it does not expose the problem. ocfs2 does not expose the problem at least on x86 since it rounds end to cluster size which is 4k minimum, on architectures with 64k pages it could be a possible problem.

Looking into the code, the handling of hole punching by  truncate_inode_pages_range() was only introduced in 3.11-rc1 and we don't have it in our 3.0-based kernels. So backporting 5a7203947a1d just does not make sense for our kernels. I guess I will just fix up OCFS2 in those kernels to avoid doing non-page-aligned calls to truncate_inode_pages_range() and be done with this.
Comment 4 Jan Kara 2017-12-15 11:06:28 UTC
After more research fixing this properly in OCFS2 would be a bigger effort effectively backporting all the framework introduced to handle partial pages in truncate_inode_pages_range(). So I don't think this is worth the effort, kABI headaches, and risk of bugs for fixing a BUG_ON in a setup nobody is likely running. So I'm closing the bug as WONTFIX for now. If some customer ever comes up with a setup where this hits, I can look into how to sanely backport all this.
Comment 6 Marcus Meissner 2018-02-09 07:59:45 UTC
will not fix