aboutsummaryrefslogtreecommitdiffstats
path: root/net/tipc/node.c
diff options
context:
space:
mode:
authorGao Xiang <[email protected]>2019-01-29 15:55:40 +0000
committerGreg Kroah-Hartman <[email protected]>2019-01-30 14:31:25 +0000
commitd4104c5e783f5d053b97268fb92001d785de7dd5 (patch)
treea61a12cb8bd9f399c677c1d3d47350ee6d75d438 /net/tipc/node.c
parentstaging: octeon: fix broken phylib usage (diff)
downloadkernel-d4104c5e783f5d053b97268fb92001d785de7dd5.tar.gz
kernel-d4104c5e783f5d053b97268fb92001d785de7dd5.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: <[email protected]> # 4.19+ Suggested-by: Al Viro <[email protected]> Signed-off-by: Gao Xiang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Diffstat (limited to 'net/tipc/node.c')
0 files changed, 0 insertions, 0 deletions