Bugzilla – Bug 956053
VUL-0: CVE-2015-8374: kernel: Btrfs: data loss, file corruption and security vulnerability when using the clone ioctl
Last modified: 2016-05-25 15:37:32 UTC
Backport the following upstream fixes: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8039d87d9e473aeb740d4fdbd59b9d2f89b2ced9 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0305cd5f7fca85dae392b9ba85b116896eb7c1c7 They fix data loss, file corruption and a vulnerability that allows a regular user (without root privileges) to read file data that was previously discarded through a truncate operation (2nd patch). Both landed in upstream kernel 4.4-rc1 and are tagged for stable releases. Their corresponding test cases for xfstests: https://git.kernel.org/cgit/fs/xfs/xfstests-dev.git/commit/?id=ddb4e4cfccfa5fc36975c12e9a66a24d3b7829bd https://git.kernel.org/cgit/fs/xfs/xfstests-dev.git/commit/?id=0e6ead559169260d0a2621ec22edcd0e63b84a88 https://git.kernel.org/cgit/fs/xfs/xfstests-dev.git/commit/?id=7ff4bb25cea7a294113f52369951db6ae52f5f9d
(In reply to Filipe Manana from comment #0) > Backport the following upstream fixes: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/ > ?id=8039d87d9e473aeb740d4fdbd59b9d2f89b2ced9 > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/ > ?id=0305cd5f7fca85dae392b9ba85b116896eb7c1c7 > > They fix data loss, file corruption and a vulnerability that allows a > regular user (without root privileges) to read file data that was previously > discarded through a truncate operation (2nd patch). Security team, should the second commit be handled as a CVE? I pulled the SLE12 backport now.
(In reply to Michal Marek from comment #1) yes, I requested a CVE and will enter it here after it is assigned. I would like to change this to a security incident if you don't object (otherwise I would clone this bug)
Re comment 2 -- Feel free to hijack this bug.
Mitre comments: Use CVE-2015-8374 for the vulnerability with the impact of "User B now gets to see the 1000 bytes that user A truncated from its file before it made its file world readable" (aka "being able to read old and stale data from foo that should not be possible to read anymore through normal filesystem operations" -- these are the 0x2a byte values). We also have the following four types of comments. As far as we know, only the first comment can affect the number of CVE IDs. (first comment) "We were also not correctly decrementing the number of bytes used by the inode, we were setting it to zero, giving a wrong report for callers of the stat(2) syscall" seems to be an entirely different type of problem, and the attacker role is different (i.e., the attacker is the user who does the truncating, not the user who does the cloning). Also, this problem could have been fixed independently. It seems that the ability of an unprivileged user to trigger incorrect data from the stat syscall can be considered a vulnerability, at least if the data can be arbitrarily incorrect. For example, in some applications, the size of a single file is critically important (e.g., a user is not allowed to have a file larger than 5 Gb because the application later directly operates on the file as a Swift object), and it's realistic to expect that privileged code sometimes uses the stat syscall to enforce this. Are there any special factors related to compressed inline extents that would cause this stat issue never to be realistically exploitable? Otherwise, we would like to assign a second CVE ID for the ability of a user to falsify stat data by truncating a file. (other comments) We don't think that "User B also lost the bytes in the range [1000, 2000[ bytes from its own file" is necessarily a critical impact. User B intentionally chose "length argument of 0, clone the whole range" and could have instead chosen a specific length that was known to be safe. (At least in some scenarios, "clone the whole range" is dangerous if there's an application with a race condition in which User A could have made the file larger after User B observed how large the whole range was.) We didn't understand "our file bar got the whole inline extent copied from foo." It seems that bar got a total of 256 bytes from foo, not the whole 512 bytes. As far as we could tell, bytes 256 through 511 of foo remained private after the attack. In general, giving one example in which everything is a multiple of 1000, followed by a mostly analogous example in which everything is a multiple of 128, might not be useful for clarifying a vulnerability.
We already have the fix in the currently running SLE 12 update. Please make sure we add the CVE to the changes file for the next update.
(is this also an issue for sle11 btrfs?)
(In reply to Marcus Meissner from comment #6) > (is this also an issue for sle11 btrfs?) It is (as it is for any upstream kernel without this fix). But for SLE11 we don't support btrfs compression, whence no need to pull this fix.
SUSE-SU-2015:2194-1: An update that solves 8 vulnerabilities and has 45 fixes is now available. Category: security (important) Bug References: 814440,867595,904348,921949,924493,930145,933514,935961,936076,936773,939826,939926,940853,941202,941867,942938,944749,945626,946078,947241,947321,947478,948521,948685,948831,949100,949463,949504,949706,949744,950013,950750,950862,950998,951110,951165,951199,951440,951546,952666,952758,953796,953980,954635,955148,955224,955422,955533,955644,956047,956053,956703,956711 CVE References: CVE-2015-0272,CVE-2015-2925,CVE-2015-5283,CVE-2015-5307,CVE-2015-7799,CVE-2015-7872,CVE-2015-7990,CVE-2015-8104 Sources used: SUSE Linux Enterprise Workstation Extension 12 (src): kernel-default-3.12.51-52.31.1 SUSE Linux Enterprise Software Development Kit 12 (src): kernel-docs-3.12.51-52.31.5, kernel-obs-build-3.12.51-52.31.1 SUSE Linux Enterprise Server 12 (src): kernel-default-3.12.51-52.31.1, kernel-source-3.12.51-52.31.1, kernel-syms-3.12.51-52.31.1, kernel-xen-3.12.51-52.31.1 SUSE Linux Enterprise Module for Public Cloud 12 (src): kernel-ec2-3.12.51-52.31.1 SUSE Linux Enterprise Live Patching 12 (src): kgraft-patch-SLE12_Update_9-1-2.2 SUSE Linux Enterprise Desktop 12 (src): kernel-default-3.12.51-52.31.1, kernel-source-3.12.51-52.31.1, kernel-syms-3.12.51-52.31.1, kernel-xen-3.12.51-52.31.1
SUSE-SU-2015:2292-1: An update that solves 7 vulnerabilities and has 54 fixes is now available. Category: security (important) Bug References: 758040,814440,904348,921949,924493,926238,933514,936773,939826,939926,940776,941113,941202,943959,944296,947241,947478,949100,949192,949706,949744,949936,950013,950580,950750,950998,951110,951165,951440,951638,951864,952384,952666,953717,953826,953830,953971,953980,954635,954986,955136,955148,955224,955354,955422,955533,955644,956047,956053,956147,956284,956703,956711,956717,956801,956876,957395,957546,958504,958510,958647 CVE References: CVE-2015-0272,CVE-2015-2925,CVE-2015-5156,CVE-2015-7799,CVE-2015-7872,CVE-2015-7990,CVE-2015-8215 Sources used: SUSE Linux Enterprise Workstation Extension 12-SP1 (src): kernel-default-3.12.51-60.20.2 SUSE Linux Enterprise Software Development Kit 12-SP1 (src): kernel-docs-3.12.51-60.20.2, kernel-obs-build-3.12.51-60.20.1 SUSE Linux Enterprise Server 12-SP1 (src): kernel-default-3.12.51-60.20.2, kernel-source-3.12.51-60.20.2, kernel-syms-3.12.51-60.20.2, kernel-xen-3.12.51-60.20.2 SUSE Linux Enterprise Module for Public Cloud 12 (src): kernel-ec2-3.12.51-60.20.2 SUSE Linux Enterprise Live Patching 12 (src): kgraft-patch-SLE12-SP1_Update_1-1-4.1 SUSE Linux Enterprise Desktop 12-SP1 (src): kernel-default-3.12.51-60.20.2, kernel-source-3.12.51-60.20.2, kernel-syms-3.12.51-60.20.2, kernel-xen-3.12.51-60.20.2
done