From: Kalle Valo <kvalo@codeaurora.org>
To: Kees Cook <keescook@chromium.org>
Cc: Willy Tarreau <w@1wt.eu>, Silvio Cesare <silvio.cesare@gmail.com>,
QCA ath9k Development <ath9k-devel@qca.qualcomm.com>,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ath9k/eeprom: Use scnprintf instead of snprintf
Date: Mon, 4 Feb 2019 15:53:20 +0000 (UTC) [thread overview]
Message-ID: <20190204155320.39CD9606AC@smtp.codeaurora.org> (raw)
In-Reply-To: <20190116000223.GA29196@beast>
Kees Cook <keescook@chromium.org> wrote:
> 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>
Patch applied to ath-next branch of ath.git, thanks.
4b6e9f3fe1d8 ath9k: eeprom: Use scnprintf instead of snprintf
--
https://patchwork.kernel.org/patch/10765259/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
prev parent reply other threads:[~2019-02-04 15:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-16 0:02 [PATCH] ath9k/eeprom: Use scnprintf instead of snprintf Kees Cook
2019-02-04 15:53 ` Kalle Valo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190204155320.39CD9606AC@smtp.codeaurora.org \
--to=kvalo@codeaurora.org \
--cc=ath9k-devel@qca.qualcomm.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=silvio.cesare@gmail.com \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.