[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e0f35083-7604-4766-990a-f77554e0202f@redhat.com>
Date: Tue, 20 Aug 2024 12:45:00 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Jeongjun Park <aha310510@...il.com>, wenjia@...ux.ibm.com,
jaka@...ux.ibm.com, alibuda@...ux.alibaba.com, tonylu@...ux.alibaba.com,
guwen@...ux.alibaba.com
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
dust.li@...ux.alibaba.com, ubraun@...ux.vnet.ibm.com, utz.bacher@...ibm.com,
linux-s390@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net,v5,2/2] net/smc: modify smc_sock structure
On 8/15/24 06:39, Jeongjun Park wrote:
> Since inet_sk(sk)->pinet6 and smc_sk(sk)->clcsock practically
> point to the same address, when smc_create_clcsk() stores the newly
> created clcsock in smc_sk(sk)->clcsock, inet_sk(sk)->pinet6 is corrupted
> into clcsock. This causes NULL pointer dereference and various other
> memory corruptions.
>
> To solve this, we need to modify the smc_sock structure.
>
> Fixes: ac7138746e14 ("smc: establish new socket family")
> Signed-off-by: Jeongjun Park <aha310510@...il.com>
> ---
> net/smc/smc.h | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/smc/smc.h b/net/smc/smc.h
> index 34b781e463c4..0d67a02a6ab1 100644
> --- a/net/smc/smc.h
> +++ b/net/smc/smc.h
> @@ -283,7 +283,10 @@ struct smc_connection {
> };
>
> struct smc_sock { /* smc sock container */
> - struct sock sk;
> + union {
> + struct sock sk;
> + struct inet_sock inet;
> + };
> struct socket *clcsock; /* internal tcp socket */
> void (*clcsk_state_change)(struct sock *sk);
> /* original stat_change fct. */
As per the running discussion here:
https://lore.kernel.org/all/5ad4de6f-48d4-4d1b-b062-e1cd2e8b3600@linux.ibm.com/#t
you should include at least a add a comment to the union, describing
which one is used in which case.
My personal preference would be directly replacing 'struct sk' with
'struct inet_sock inet;' and adjust all the smc->sk access accordingly,
likely via a new helper.
I understand that would be much more invasive, but would align with
other AF.
Thanks,
Paolo
Powered by blists - more mailing lists