It's possible that the destination can be shadowed in userspace
(as, for example, the perf buffers are now). So we should take
care not to leak data that could be inspected by userspace.
Signed-off-by: Chris Metcalf <cmetc...@ezchip.com>
---
Ingo, can you test this change in your Fedora+strlcpy boot test?
I think it's correct but the more testing the better, particularly
if we're about to add the support for strlcpy to use it.
I did some light testing on big-endian tilegx and it appears
that zero_bytemask() is required and does the right thing.
On little-endian it's generally a no-op. This is pretty much
the same pattern that fs/namei.c uses now too.
lib/string.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/string.c b/lib/string.c
index 8dbb7b1eab50..84775ba873b9 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -203,12 +203,13 @@ ssize_t strscpy(char *dest, const char *src, size_t count)
unsigned long c, data;
c = *(unsigned long *)(src+res);
- *(unsigned long *)(dest+res) = c;
if (has_zero(c, &data, &constants)) {
data = prep_zero_mask(c, data, &constants);
data = create_zero_mask(data);
+ *(unsigned long *)(dest+res) = c & zero_bytemask(data);
return res + find_zero(data);
}
+ *(unsigned long *)(dest+res) = c;
res += sizeof(unsigned long);
count -= sizeof(unsigned long);
max -= sizeof(unsigned long);
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
