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

Issue 888329 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 1
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug-Security



Sign in to add a comment

CVE-2018-14617 CrOS: Vulnerability reported in Linux kernel

Project Member Reported by vomit.go...@appspot.gserviceaccount.com, Sep 23

Issue description

VOMIT (go/vomit) has received an external vulnerability report for the Linux kernel. 

Advisory: CVE-2018-14617
  Details: http://vomit.googleplex.com/advisory?id=CVE/CVE-2018-14617
  CVSS severity score: 7.1/10.0
  Description:

An issue was discovered in the Linux kernel through 4.17.10. There is a NULL pointer dereference and panic in hfsplus_lookup() in fs/hfsplus/dir.c when opening a file (that is purportedly a hard link) in an hfs+ filesystem that has malformed catalog data, and is mounted read-only without a metadata directory.



This bug was filed by http://go/vomit
Please contact us at vomit-team@google.com if you need any assistance.

 
Cc: groeck@chromium.org sawlani@google.com wonderfly@google.com
Labels: Security_Severity-High Security_Impact-Stable Pri-1
Owner: zsm@chromium.org
Status: Assigned (was: Untriaged)
Upstream commit is a7ec7a4193a("hfsplus: fix NULL dereference in hfsplus_lookup()")

This commit is present in v4.14, v4.4. Older kernels do not have this commit. The commit is not present in 3.18.y.

There is a minor conflict when applying the patches as upstream uses "HFSPLUS_I(sb->s_root->d_inode)" instead of "HFSPLUS_I(d_inode(sb->s_root))"
Project Member

Comment 2 by sheriffbot@chromium.org, Sep 25

Labels: M-69 Target-69
Project Member

Comment 5 by bugdroid1@chromium.org, Sep 29

Labels: merge-merged-chromeos-3.10
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c1a2234c618b383d0ce186d12edea40606eeb9a9

commit c1a2234c618b383d0ce186d12edea40606eeb9a9
Author: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com>
Date: Sat Sep 29 03:37:10 2018

UPSTREAM: hfsplus: fix NULL dereference in hfsplus_lookup()

An HFS+ filesystem can be mounted read-only without having a metadata
directory, which is needed to support hardlinks.  But if the catalog
data is corrupted, a directory lookup may still find dentries claiming
to be hardlinks.

hfsplus_lookup() does check that ->hidden_dir is not NULL in such a
situation, but mistakenly does so after dereferencing it for the first
time.  Reorder this check to prevent a crash.

This happens when looking up corrupted catalog data (dentry) on a
filesystem with no metadata directory (this could only ever happen on a
read-only mount).  Wen Xu sent the replication steps in detail to the
fsdevel list: https://bugzilla.kernel.org/show_bug.cgi?id=200297

BUG= chromium:888329 
TEST=None

Conflict Note:
The patch applied is the same as upstream. When applying the patch there
is a conflict as upstream uses
	HFSPLUS_I(d_inode(sb->s_root))
while v3.18 uses
	HFSPLUS_I(sb->s_root->d_inode)

in order to obtain the hfsplus_inode_info.

Change-Id: I81e6832f26d34c95ec84e089cd623c752f60724a
Link: http://lkml.kernel.org/r/20180712215344.q44dyrhymm4ajkao@eaf
Signed-off-by: Ernesto A. Fernndez <ernesto.mnd.fernandez@gmail.com>
Reported-by: Wen Xu <wen.xu@gatech.edu>
Cc: Viacheslav Dubeyko <slava@dubeyko.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit a7ec7a4193a2eb3b5341243fc0b621c1ac9e4ec4)
Signed-off-by: Zubin Mithra <zsm@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1252543

[modify] https://crrev.com/c1a2234c618b383d0ce186d12edea40606eeb9a9/fs/hfsplus/dir.c

Project Member

Comment 6 by bugdroid1@chromium.org, Oct 1

Labels: merge-merged-chromeos-3.14
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7829502fae3089f204903fa47507feafccfcd70e

commit 7829502fae3089f204903fa47507feafccfcd70e
Author: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com>
Date: Mon Oct 01 18:30:50 2018

UPSTREAM: hfsplus: fix NULL dereference in hfsplus_lookup()

An HFS+ filesystem can be mounted read-only without having a metadata
directory, which is needed to support hardlinks.  But if the catalog
data is corrupted, a directory lookup may still find dentries claiming
to be hardlinks.

hfsplus_lookup() does check that ->hidden_dir is not NULL in such a
situation, but mistakenly does so after dereferencing it for the first
time.  Reorder this check to prevent a crash.

This happens when looking up corrupted catalog data (dentry) on a
filesystem with no metadata directory (this could only ever happen on a
read-only mount).  Wen Xu sent the replication steps in detail to the
fsdevel list: https://bugzilla.kernel.org/show_bug.cgi?id=200297

BUG= chromium:888329 
TEST=None

Conflict Note:
The patch applied is the same as upstream. When applying the patch there
is a conflict as upstream uses
	HFSPLUS_I(d_inode(sb->s_root))
while v3.18 uses
	HFSPLUS_I(sb->s_root->d_inode)

in order to obtain the hfsplus_inode_info.

Change-Id: I81e6832f26d34c95ec84e089cd623c752f60724a
Link: http://lkml.kernel.org/r/20180712215344.q44dyrhymm4ajkao@eaf
Signed-off-by: Ernesto A. Fernndez <ernesto.mnd.fernandez@gmail.com>
Reported-by: Wen Xu <wen.xu@gatech.edu>
Cc: Viacheslav Dubeyko <slava@dubeyko.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit a7ec7a4193a2eb3b5341243fc0b621c1ac9e4ec4)
Signed-off-by: Zubin Mithra <zsm@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1252542

[modify] https://crrev.com/7829502fae3089f204903fa47507feafccfcd70e/fs/hfsplus/dir.c

Project Member

Comment 7 by bugdroid1@chromium.org, Oct 1

Labels: merge-merged-chromeos-3.18
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/91c203dff9ad858ca19458e11748b05b62e2a0b7

commit 91c203dff9ad858ca19458e11748b05b62e2a0b7
Author: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com>
Date: Mon Oct 01 18:30:59 2018

UPSTREAM: hfsplus: fix NULL dereference in hfsplus_lookup()

An HFS+ filesystem can be mounted read-only without having a metadata
directory, which is needed to support hardlinks.  But if the catalog
data is corrupted, a directory lookup may still find dentries claiming
to be hardlinks.

hfsplus_lookup() does check that ->hidden_dir is not NULL in such a
situation, but mistakenly does so after dereferencing it for the first
time.  Reorder this check to prevent a crash.

This happens when looking up corrupted catalog data (dentry) on a
filesystem with no metadata directory (this could only ever happen on a
read-only mount).  Wen Xu sent the replication steps in detail to the
fsdevel list: https://bugzilla.kernel.org/show_bug.cgi?id=200297

BUG= chromium:888329 
TEST=None

Conflict Note:
The patch applied is the same as upstream. When applying the patch there
is a conflict as upstream uses
	HFSPLUS_I(d_inode(sb->s_root))
while v3.18 uses
	HFSPLUS_I(sb->s_root->d_inode)

in order to obtain the hfsplus_inode_info.

Change-Id: I81e6832f26d34c95ec84e089cd623c752f60724a
Link: http://lkml.kernel.org/r/20180712215344.q44dyrhymm4ajkao@eaf
Signed-off-by: Ernesto A. Fernndez <ernesto.mnd.fernandez@gmail.com>
Reported-by: Wen Xu <wen.xu@gatech.edu>
Cc: Viacheslav Dubeyko <slava@dubeyko.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit a7ec7a4193a2eb3b5341243fc0b621c1ac9e4ec4)
Signed-off-by: Zubin Mithra <zsm@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1241534

[modify] https://crrev.com/91c203dff9ad858ca19458e11748b05b62e2a0b7/fs/hfsplus/dir.c

Status: Fixed (was: Assigned)
Project Member

Comment 9 by bugdroid1@chromium.org, Oct 1

Labels: merge-merged-chromeos-3.8
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5fc5a6883b64340d8d5038ee79321b0750b4e2a4

commit 5fc5a6883b64340d8d5038ee79321b0750b4e2a4
Author: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com>
Date: Mon Oct 01 18:31:02 2018

UPSTREAM: hfsplus: fix NULL dereference in hfsplus_lookup()

An HFS+ filesystem can be mounted read-only without having a metadata
directory, which is needed to support hardlinks.  But if the catalog
data is corrupted, a directory lookup may still find dentries claiming
to be hardlinks.

hfsplus_lookup() does check that ->hidden_dir is not NULL in such a
situation, but mistakenly does so after dereferencing it for the first
time.  Reorder this check to prevent a crash.

This happens when looking up corrupted catalog data (dentry) on a
filesystem with no metadata directory (this could only ever happen on a
read-only mount).  Wen Xu sent the replication steps in detail to the
fsdevel list: https://bugzilla.kernel.org/show_bug.cgi?id=200297

BUG= chromium:888329 
TEST=None

Conflict Note:
The patch applied is the same as upstream. When applying the patch there
is a conflict as upstream uses
	HFSPLUS_I(d_inode(sb->s_root))
while v3.18 uses
	HFSPLUS_I(sb->s_root->d_inode)

in order to obtain the hfsplus_inode_info.

Change-Id: I81e6832f26d34c95ec84e089cd623c752f60724a
Link: http://lkml.kernel.org/r/20180712215344.q44dyrhymm4ajkao@eaf
Signed-off-by: Ernesto A. Fernndez <ernesto.mnd.fernandez@gmail.com>
Reported-by: Wen Xu <wen.xu@gatech.edu>
Cc: Viacheslav Dubeyko <slava@dubeyko.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit a7ec7a4193a2eb3b5341243fc0b621c1ac9e4ec4)
Signed-off-by: Zubin Mithra <zsm@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1252544

[modify] https://crrev.com/5fc5a6883b64340d8d5038ee79321b0750b4e2a4/fs/hfsplus/dir.c

Project Member

Comment 10 by sheriffbot@chromium.org, Oct 2

Labels: Restrict-View-SecurityNotify
Project Member

Comment 11 by sheriffbot@chromium.org, Jan 8

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