Bug 1102865 - (CVE-2018-14615) VUL-0: CVE-2018-14615: kernel: buffer overflow in truncate_inline_inode() in fs/f2fs/inline.c when umounting an f2fsimage
VUL-0: CVE-2018-14615: kernel: buffer overflow in truncate_inline_inode() in ...
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Security
Leap 42.3
Other Other
: P3 - Medium : Normal (vote)
: ---
Assigned To: Nikolay Borisov
Security Team bot
Depends on:
  Show dependency treegraph
Reported: 2018-07-27 10:58 UTC by Johannes Segitz
Modified: 2018-10-04 13:08 UTC (History)
2 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 2018-07-27 10:58:49 UTC

An issue was discovered in the Linux kernel through 4.17.10. There is a buffer
overflow in truncate_inline_inode() in fs/f2fs/inline.c when umounting an f2fs
image, because a length value may be negative.

f2fs => openSUSE only

Comment 2 Nikolay Borisov 2018-09-14 09:33:40 UTC
I'm starting to seriously question the viability of doing any sort of CVE fixes for f2fs. This bug for example results from fuzzing a field for an F2FS feature which was added in upstream commit 7a2af766af15 ("f2fs: enhance on-disk inode structure scalability") which is an on-disk format change. Yet, it seems that f2fs doesn't really check if the inode it is reading contains feature that the current implementation doesn't understand. openSUSE 42.3 for example doesn't have support for this feature, yet is able to read the inode, possibly mis-identify the data stored at i_addr and as a result crashes on unmount but not when the PoC is run. 

For this particular CVE what I intend on doing is to just refuse to parse inodes which contain features that are not recognised by current implementation. However, the bigger question is whether it makes sense to have f2fs enabled since the design of the filesystem apparently caters to a rather narrow use case where the user knows what version of on-disk metadata he is having. As such does it even make sense to have it enabled in our community kernel ?
Comment 3 Nikolay Borisov 2018-10-02 07:47:59 UTC
As per https://bugzilla.opensuse.org/show_bug.cgi?id=1109665 closing as Won't Fix since f2fs is no longer supported on opensuse.
Comment 4 Marcus Meissner 2018-10-04 13:08:21 UTC
remove needinfo