summaryrefslogtreecommitdiff
path: root/scripts/gdb/linux/proc.py
diff options
context:
space:
mode:
authorGao Xiang <gaoxiang25@huawei.com>2019-02-01 20:16:31 +0800
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-03-13 14:01:31 -0700
commita56c9e2637868f859107ab110b352f9e8fd4890f (patch)
treed2171104417dcf4e7a0a48e34c8655b5e07238e4 /scripts/gdb/linux/proc.py
parent66ad3d56ab6246f20c4ff9c120731c890d015c65 (diff)
staging: erofs: keep corrupted fs from crashing kernel in erofs_namei()
commit 419d6efc50e94bcf5d6b35cd8c71f79edadec564 upstream. 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 'scripts/gdb/linux/proc.py')
0 files changed, 0 insertions, 0 deletions