diff options
| author | Gao Xiang <gaoxiang25@huawei.com> | 2019-02-01 20:16:31 +0800 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2019-02-14 10:47:21 +0100 |
| commit | 419d6efc50e94bcf5d6b35cd8c71f79edadec564 (patch) | |
| tree | c9c2069905ad3133f834efa6f3845b6414c4bdd1 /tools/perf/scripts/python/bin | |
| parent | staging: rtl8192e: rename macro arguments to avoid camel case - style (diff) | |
| download | linux-419d6efc50e94bcf5d6b35cd8c71f79edadec564.tar.gz linux-419d6efc50e94bcf5d6b35cd8c71f79edadec564.zip | |
staging: erofs: keep corrupted fs from crashing kernel in erofs_namei()
As Al pointed out, "
... and while we are at it, what happens to
unsigned int nameoff = le16_to_cpu(de[mid].nameoff);
unsigned int matched = min(startprfx, endprfx);
struct qstr dname = QSTR_INIT(data + nameoff,
unlikely(mid >= ndirents - 1) ?
maxsize - nameoff :
le16_to_cpu(de[mid + 1].nameoff) - nameoff);
/* string comparison without already matched prefix */
int ret = dirnamecmp(name, &dname, &matched);
if le16_to_cpu(de[...].nameoff) is not monotonically increasing? I.e.
what's to prevent e.g. (unsigned)-1 ending up in dname.len?
Corrupted fs image shouldn't oops the kernel.. "
Revisit the related lookup flow to address the issue.
Fixes: d72d1ce60174 ("staging: erofs: add namei functions")
Cc: <stable@vger.kernel.org> # 4.19+
Suggested-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'tools/perf/scripts/python/bin')
0 files changed, 0 insertions, 0 deletions
