New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 835889 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug-Security



Sign in to add a comment

Various filesystem CVEs

Project Member Reported by groeck@chromium.org, Apr 23 2018

Issue description

CVE-2018-1092 kernel: NULL pointer dereference in ext4/mballoc.c:ext4_process_freed_data() when mounting crafted ext4 image

The Linux kernel through version 4.15 is vulnerable to a NULL pointer dereference
in the ext4/mballoc.c:ext4_process_freed_data() function. An attacker with
privileged access could exploit this by mounting a crafted ext4 image to cause a kernel panic.

References:
https://bugzilla.kernel.org/show_bug.cgi?id=199179
https://bugzilla.redhat.com/show_bug.cgi?id=1560777

=====

CVE-2018-1093 kernel: Out of bounds read in ext4/balloc.c:ext4_valid_block_bitmap() causes crash with crafted ext4 image

The Linux kernel through version 4.15 is vulnerable to an out-of-bounds
read in ext4/balloc.c:ext4_valid_block_bitmap() function. An privileged
attacker could exploit this by mounting a crafted ext4 image to cause a crash.

References:
https://bugzilla.kernel.org/show_bug.cgi?id=199181
https://bugzilla.redhat.com/show_bug.cgi?id=1560782

=====

CVE-2018-1094 kernel: NULL pointer dereference in ext4/xattr.c:ext4_xattr_inode_hash() causes crash with crafted ext4 image

The Linux kernel through version 4.15 is vulnerable to a NULL pointer dereference
in the ext4/xattr.c:ext4_xattr_inode_hash() function. A privileged attacker could
exploit this to cause a NULL pointer dereference with a crafted ext4 image.

References:
https://bugzilla.kernel.org/show_bug.cgi?id=199183
https://bugzilla.redhat.com/show_bug.cgi?id=1560788

=====

CVE-2018-1095 kernel: NULL pointer dereference in fs/posix_acl.c:get_acl() causes crash with crafted ext4 image

The Linux kernel through version 4.15 is vulnerable to a NULL pointer
dereference in the  fs/posix_acl.c:get_acl()function. A privileged attacker
could exploit this to cause a NULL pointer dereference with a crafted ext4
image.

References:

https://bugzilla.kernel.org/show_bug.cgi?id=199185
https://bugzilla.redhat.com/show_bug.cgi?id=1560793
 

Comment 1 by groeck@chromium.org, Apr 23 2018

CVE-2018-1092:

Upstream commit 8e4b5eae5de ("ext4: fail ext4_iget for root directory if unallocated"). No CVE severity assigned. Queued for v4.14.36, v4.4.129.

CVE-2018-1093:

Upstream commit 7dac4a1726a9 ("ext4: add validity checks for bitmap block numbers"). No CVE severity assigned. Not (yet) queued for any stable releases, but marked for stable.

CVE-2018-1094:

Upstream commits 18db4b4e6fc ("ext4: don't allow r/w mounts if metadata blocks overlap the superblock") and a45403b515 ("ext4: always initialize the crc32c checksum driver"). No CVE severity assigned. 1st patch queued for v4.4.129 and v4.14.36. Second patch queued for v4.14.36; v4.4 does not appear to be affected.

CVE-2018-1095:

Upstream commit ce3fd194fc ("ext4: limit xattr size to INT_MAX"). No CVE severity assigned. 4.4 not affected. Queued for v4.14.36.

Comment 2 by groeck@chromium.org, Apr 23 2018

Cc: mnissler@chromium.org
Labels: CVE-2018-1094 CVE-2018-1095 CVE-2018-1092 CVE-2018-1093
Adding CVE labels per security team's decision to make an effort to make this information more accessible in a more structured way.
Project Member

Comment 4 by sheriffbot@chromium.org, Apr 24 2018

Labels: -Pri-3 Pri-2

Comment 5 by groeck@chromium.org, Apr 25 2018

Update for CVE-2018-1093:

Upstream commit 7dac4a1726a9 ("ext4: add validity checks for bitmap block numbers") was not pulled into stable releases because it causes a regression. See 
https://marc.info/?l=linux-ext4&m=152416385122029&w=2 for details.
Do _not_ pulled into any stable releases until the problem has been fixed.

Labels: CVE_description-submitted

Comment 7 by groeck@chromium.org, Apr 29 2018

All CVEs except for CVE-2018-1093 are fixed in chromeos-4.4 and chromeos-4.14.
The fix for commit 7dac4a1726a9 is 22be37acce25 ("ext4: fix bitmap position validation"). Both are not yet available in any stable release.

Cc: adityakali@google.com
Guenter, do you know why Vomit didn't report these? Also, it seems that all four CVEs can only be exploited by the root user?

Comment 9 by groeck@chromium.org, Apr 30 2018

#8:
- Part 1: no, I don't know why Vomit did not report those. It may be because the information in the CVEs is sparse; they are still "undergoing analysis".
- Part 2: I tend to disagree (and was hoping for the CVE analysis to conclude). AFAIK it is possible to mount a USB stick without explicit root permission; for example, ChromeOS auto-mounts USB sticks (or any other external drive, for that matter), and so do Ubuntu systems.

The patches fixing for CVE-2018-1093 are queued for v4.14.39, v4.4.131, and v3.18.108.



Cc: sawlani@google.com
+sawlani, the CVEs show up on Vomit now.
Im looking at CVE-2018-1093.
Ahh saw the update from groeck@, I will make sure this fixed in all our valid branches. 
Labels: M-68
Marking for M-68 (ie no stable release merges) per jorgelo@'s tags in individual CVEs.

jorgelo@, As per COS CVE policy these patches are needed for stable milestone as well.  I was wondering why ChromeOS CVE policy and COS policy differ?

COS is just another ChromeOS board(lakitu) See go/cos for details.
You can find COS CVE policy at go/cos-cve. 



Cc: -adityakali@google.com jorgelo@chromium.org
Cc: adityakali@google.com
Note that ChromeOS has a different kernel config but more importantly a very different use case than Lakitu (one is a client while the other is a server). I am not surprised their CVE patching policies differ. COS' policy was derived from Google's production server policy which is more comparable.

That said, we (COS) could still patch milestones we think are important, regardless of ChromeOS wants to do it for their images.
Re c#15: Mostly what Daniel said in c#18. The use cases are very different, even if the actual source code is shared. More importantly, the policies were developed independently, taking into account these different use cases.

Having said that, I'm sure we can find ways to harmonize the policies, as much as it makes sense, to make our lives easier.
Status: Fixed (was: Assigned)
CVE-2018-1093 is now also fixed in both chromeos-4.4 and chromeos-4.14. Closing as fixed.

Final words on policy: What makes life difficult for me is any deviation from official CVE severity ratings that goes beyond "not enabled in any images", since it involves second-guessing, takes time, and increases risk - even more so that we are now contemplating to enable new features such as kvm as far back as chromeos.3.14.

Project Member

Comment 21 by sheriffbot@chromium.org, May 17 2018

Labels: Restrict-View-SecurityNotify
Project Member

Comment 22 by sheriffbot@chromium.org, Aug 23

Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment