From: Al Viro <viro@zeniv.linux.org.uk>
To: Philipp Stanner <pstanner@redhat.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Stanislav Fomichev <sdf@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Benjamin Tissoires <benjamin.tissoires@redhat.com>,
linux-ppp@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH] drivers/net/ppp: copy userspace array safely
Date: Thu, 2 Nov 2023 22:30:17 +0000 [thread overview]
Message-ID: <20231102223017.GO1957730@ZenIV> (raw)
In-Reply-To: <7a26cd1bafb22b16eab3868255706d44fa4f255d.camel@redhat.com>
On Thu, Nov 02, 2023 at 11:02:35PM +0100, Philipp Stanner wrote:
> We introduced those wrappers to string.h hoping they will be useful.
> Now that they're merged, I quickly wanted to establish them as the
> standard for copying user-arrays, ideally in the current merge window.
> Because its convenient, easy to read and, at times, safer.
They also save future readers a git grep to find the sizes, etc.
Again, the only suggestion is that regarding the commit message;
_some_ of those might end up fixing real overflows and you obviously
want to see how far do those need to be backported, etc. And "in this
case the overflow doesn't actually happen because <reasons>, but
not having to do such analysis is a good thing" is not a bad explanation
why the primitive in question is useful, IMO. Granted, in cases like
256 * sizeof(u32) that would be pointless, but for the ones that
are less obvious...
> I just didn't see it in ppp. Maybe I should have looked more
> intensively for all 13 patches. But we'll get there, that's what v2 and
> v3 are for :)
In any case you want to check if there are real bugs caught in that.
prev parent reply other threads:[~2023-11-02 22:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-02 19:19 [PATCH] drivers/net/ppp: copy userspace array safely Philipp Stanner
2023-11-02 20:09 ` Al Viro
2023-11-02 22:02 ` Philipp Stanner
2023-11-02 22:30 ` Al Viro [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=20231102223017.GO1957730@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=airlied@redhat.com \
--cc=benjamin.tissoires@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-ppp@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pstanner@redhat.com \
--cc=sdf@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).