summaryrefslogtreecommitdiff
path: root/fs/fscache
diff options
context:
space:
mode:
authorKees Cook <keescook@chromium.org>2019-01-15 16:02:23 -0800
committerKalle Valo <kvalo@codeaurora.org>2019-02-04 17:52:49 +0200
commit4b6e9f3fe1d8af03ddbd484d5ea30344e5115d5f (patch)
tree0e7a73451cbef062801530f389bf7ef56381042b /fs/fscache
parent5cbb117477501df2f8b3a384b042b08cd7174c92 (diff)
ath9k: eeprom: Use scnprintf instead of snprintf
Change snprintf to scnprintf. There are generally two cases where using snprintf causes problems. 1) Uses of size += snprintf(buf, SIZE - size, fmt, ...) In this case, if snprintf would have written more characters than what the buffer size (SIZE) is, then size will end up larger than SIZE. In later uses of snprintf, SIZE - size will result in a negative number, leading to problems. Note that size might already be too large by using size = snprintf before the code reaches a case of size += snprintf. 2) If size is ultimately used as a length parameter for a copy back to user space, then it will potentially allow for a buffer overflow and information disclosure when size is greater than SIZE. When the size is used to index the buffer directly, we can have memory corruption. This also means when size = snprintf... is used, it may also cause problems since size may become large. Copying to userspace is mitigated by the HARDENED_USERCOPY kernel configuration. The solution to these issues is to use scnprintf which returns the number of characters actually written to the buffer, so the size variable will never exceed SIZE. Cc: Willy Tarreau <w@1wt.eu> Cc: Silvio Cesare <silvio.cesare@gmail.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Diffstat (limited to 'fs/fscache')
0 files changed, 0 insertions, 0 deletions