From: Jakub Kicinski <kuba@kernel.org>
To: Kuniyuki Iwashima <kuniyu@amazon.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Patrick McHardy <kaber@trash.net>,
Pablo Neira Ayuso <pablo@netfilter.org>,
Christophe Ricard <christophe-h.ricard@st.com>,
Johannes Berg <johannes.berg@intel.com>,
David Ahern <dsahern@gmail.com>,
Kuniyuki Iwashima <kuni1840@gmail.com>, <netdev@vger.kernel.org>,
Brad Spencer <bspencer@blackberry.com>
Subject: Re: [PATCH v1 net] netlink: Use copy_to_user() for optval in netlink_getsockopt().
Date: Tue, 18 Apr 2023 20:33:18 -0700 [thread overview]
Message-ID: <20230418203318.2053c4f9@kernel.org> (raw)
In-Reply-To: <20230419004246.25770-1-kuniyu@amazon.com>
On Tue, 18 Apr 2023 17:42:46 -0700 Kuniyuki Iwashima wrote:
> Brad Spencer provided a detailed report that when calling getsockopt()
> for AF_NETLINK, some SOL_NETLINK options set only 1 byte even though such
> options require more than int as length.
>
> The options return a flag value that fits into 1 byte, but such behaviour
> confuses users who do not strictly check the value as char.
>
> Currently, netlink_getsockopt() uses put_user() to copy data to optlen and
> optval, but put_user() casts the data based on the pointer, char *optval.
> So, only 1 byte is set to optval.
>
> To avoid this behaviour, we need to use copy_to_user() or cast optval for
> put_user().
>
> Now getsockopt() accepts char as optval as the flags are only 1 byte.
I think it's worth doing, but it will change the return value on big
endian, right?
next prev parent reply other threads:[~2023-04-19 3:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 0:42 [PATCH v1 net] netlink: Use copy_to_user() for optval in netlink_getsockopt() Kuniyuki Iwashima
2023-04-19 3:33 ` Jakub Kicinski [this message]
2023-04-19 17:50 ` Kuniyuki Iwashima
2023-04-19 7:17 ` Johannes Berg
2023-04-19 17:52 ` Kuniyuki Iwashima
2023-04-19 19:46 ` Johannes Berg
2023-04-19 19:47 ` Johannes Berg
[not found] ` <20230419160908.5469e9bf@kernel.org>
2023-04-20 3:40 ` Kuniyuki Iwashima
2023-04-20 7:04 ` Johannes Berg
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=20230418203318.2053c4f9@kernel.org \
--to=kuba@kernel.org \
--cc=bspencer@blackberry.com \
--cc=christophe-h.ricard@st.com \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=edumazet@google.com \
--cc=johannes.berg@intel.com \
--cc=kaber@trash.net \
--cc=kuni1840@gmail.com \
--cc=kuniyu@amazon.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
/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.