From: Dmitry Safonov <0x7f454c46@gmail.com>
To: Anastasia Belova <abelova@astralinux.ru>,
Steffen Klassert <steffen.klassert@secunet.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
lvc-project@linuxtesting.org
Subject: Re: [PATCH] xfrm: compat: change expression for switch in xfrm_xlate64
Date: Tue, 10 Jan 2023 17:32:15 +0000 [thread overview]
Message-ID: <a2821ac8-6903-372e-36a4-9667b9fceac2@gmail.com> (raw)
In-Reply-To: <20230110091450.21696-1-abelova@astralinux.ru>
On 1/10/23 09:14, Anastasia Belova wrote:
> Compare XFRM_MSG_NEWSPDINFO (value from netlink
> configuration messages enum) with nlh_src->nlmsg_type
> instead of nlh_src->nlmsg_type - XFRM_MSG_BASE.
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
Nice find!
Looking at the details:
xfrm_xlate64() is for translating 64-bit kernel-issued message to 32-bit
userspace ABI. The message is XFRM_MSG_NEWSPDINFO and there's a selftest
that checks if the attributes (thresh valued) were correctly translated
in tools/testing/selftests/net/ipsec.c
So, I was interested in how did it go unnoticed?
The switch here is to differ XFRMA_* attributes from XFRMA_SPD_*
attributes, which can be just copied as they are as they occupy the same
space on 64-bit as well as on 32-bit.
enum xfrm_spdattr_type_t {
XFRMA_SPD_UNSPEC,
XFRMA_SPD_INFO,
XFRMA_SPD_HINFO,
XFRMA_SPD_IPV4_HTHRESH,
XFRMA_SPD_IPV6_HTHRESH,
__XFRMA_SPD_MAX
};
attributes went through xfrm_xlate64_attr() instead of just being
copied. That worked in result as
case XFRMA_UNSPEC:
case XFRMA_ALG_AUTH:
case XFRMA_ALG_CRYPT:
case XFRMA_ALG_COMP:
case XFRMA_ENCAP:
case XFRMA_TMPL:
return xfrm_nla_cpy(dst, src, nla_len(src));
are equal by value (XFRMA_UNSPEC == 0 == XFRMA_SPD_UNSPEC) and so on.
So, in result, even with this typo the code worked.
What about the reverse case, what was being copied by this
XFRM_MSG_NEWSPDINFO case?
XFRM_MSG_NEWSPDINFO == 0x24
So, before this patch (XFRM_MSG_NEWSPDINFO - XFRM_MSG_BASE) == 0x14 ==
XFRM_MSG_DELPOLICY type of messages would fit this switch case.
Luckily enough, kernel doesn't send back XFRM_MSG_DELPOLICY messages to
userspace. That's how it went unnoticed, by unexpectedly still working.
> Fixes: 4e9505064f58 ("net/xfrm/compat: Copy xfrm_spdattr_type_t atributes")
> Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
Thanks for the patch,
Acked-by: Dmitry Safonov <0x7f454c46@gmail.com>
Tested-by: Dmitry Safonov <0x7f454c46@gmail.com>
> ---
> net/xfrm/xfrm_compat.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/xfrm/xfrm_compat.c b/net/xfrm/xfrm_compat.c
> index a0f62fa02e06..12405aa5bce8 100644
> --- a/net/xfrm/xfrm_compat.c
> +++ b/net/xfrm/xfrm_compat.c
> @@ -302,7 +302,7 @@ static int xfrm_xlate64(struct sk_buff *dst, const struct nlmsghdr *nlh_src)
> nla_for_each_attr(nla, attrs, len, remaining) {
> int err;
>
> - switch (type) {
> + switch (nlh_src->nlmsg_type) {
> case XFRM_MSG_NEWSPDINFO:
> err = xfrm_nla_cpy(dst, nla, nla_len(nla));
> break;
next prev parent reply other threads:[~2023-01-10 17:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-10 9:14 Anastasia Belova
2023-01-10 17:32 ` Dmitry Safonov [this message]
2023-01-16 13:01 ` Steffen Klassert
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=a2821ac8-6903-372e-36a4-9667b9fceac2@gmail.com \
--to=0x7f454c46@gmail.com \
--cc=abelova@astralinux.ru \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=steffen.klassert@secunet.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
all inboxes | Powered by JetHome®