From: Jakub Kicinski <kuba@kernel.org>
To: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Cc: Kees Cook <keescook@chromium.org>,
David Ahern <dsahern@kernel.org>,
davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
pabeni@redhat.com, linux-hardening@vger.kernel.org
Subject: Re: [PATCH net-next v2] netlink: split up copies in the ack construction
Date: Wed, 16 Nov 2022 22:13:06 -0800 [thread overview]
Message-ID: <20221116221306.5a4bd5f8@kernel.org> (raw)
In-Reply-To: <1b373b08-988d-b870-d363-814f8083157c@embeddedor.com>
On Wed, 16 Nov 2022 19:20:51 -0600 Gustavo A. R. Silva wrote:
> On 11/16/22 19:05, Jakub Kicinski wrote:
> >> This seems to be a sensible change. In general, it's not a good idea
> >> to have variable length objects (flex-array members) in structures used
> >> as headers, and that we know will ultimately be followed by more objects
> >> when embedded inside other structures.
> >
> > Meaning we should go back to zero-length arrays instead?
>
> No.
I was asking based on your own commit 1e6e9d0f4859 ("uapi: revert
flexible-array conversions"). This is uAPI as well.
Since we can't prevent user space from wrapping structures seems
like adding a flex member to an existing struct should never be
permitted in uAPI headers? We can just wrap things locally, I guess:
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 9ebdf3262015..2af2f8de4043 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -2479,7 +2479,10 @@ void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err,
{
struct sk_buff *skb;
struct nlmsghdr *rep;
- struct nlmsgerr *errmsg;
+ struct hashtag_silly {
+ struct nlmsgerr err;
+ u8 data[];
+ } *errmsg;
size_t payload = sizeof(*errmsg);
struct netlink_sock *nlk = nlk_sk(NETLINK_CB(in_skb).sk);
unsigned int flags = 0;
@@ -2507,15 +2510,14 @@ void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err,
if (!rep)
goto err_bad_put;
errmsg = nlmsg_data(rep);
- errmsg->error = err;
- errmsg->msg = *nlh;
+ errmsg->err.error = err;
+ errmsg->err.msg = *nlh;
if (!(flags & NLM_F_CAPPED)) {
if (!nlmsg_append(skb, nlmsg_len(nlh)))
goto err_bad_put;
- memcpy(errmsg->msg.nlmsg_data, nlh->nlmsg_data,
- nlmsg_len(nlh));
+ memcpy(errmsg->data, nlmsg_data(nlh), nlmsg_len(nlh));
}
if (tlvlen)
In this particular case, tho, we're probably better off giving up
on the flex array and doing nlmsg_data() on both src and dst.
> > Is there something in the standard that makes flexible array
> > at the end of an embedded struct a problem?
>
> I haven't seen any problems ss long as the flex-array appears last:
>
> struct foo {
> ... members
> struct boo {
> ... members
> char flex[];
> };
> };
>
> struct complex {
> ... members
> struct foo embedded;
> };
>
> However, the GCC docs[1] mention this:
>
> "A structure containing a flexible array member [..] may not be a
> member of a structure [..] (However, these uses are permitted by GCC
> as extensions.)"
>
> And in this case it seems that's the reason why GCC doesn't complain?
Seems so, clang's warning is called -Wgnu-variable-sized-type-not-at-end
next prev parent reply other threads:[~2022-11-17 6:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-27 21:25 [PATCH net-next v2] netlink: split up copies in the ack construction Jakub Kicinski
2022-10-31 9:20 ` patchwork-bot+netdevbpf
2022-11-14 2:39 ` David Ahern
2022-11-14 17:06 ` Jakub Kicinski
2022-11-16 22:53 ` Kees Cook
2022-11-16 22:56 ` Kees Cook
2022-11-17 0:27 ` Kees Cook
2022-11-17 0:55 ` Gustavo A. R. Silva
2022-11-17 1:05 ` Jakub Kicinski
2022-11-17 1:20 ` Gustavo A. R. Silva
2022-11-17 6:13 ` Jakub Kicinski [this message]
2022-11-17 16:25 ` Stephen Hemminger
2022-11-17 20:36 ` Jakub Kicinski
2022-11-17 22:35 ` Kees Cook
2022-11-18 0:28 ` Jakub Kicinski
2022-11-18 3:27 ` Kees Cook
2022-11-18 15:59 ` David Ahern
2022-11-18 2:37 ` Stephen Hemminger
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=20221116221306.5a4bd5f8@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=gustavo@embeddedor.com \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 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.