public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeongjun Park <aha310510@gmail.com>
To: "D. Wythe" <alibuda@linux.alibaba.com>
Cc: davem@davemloft.net, dust.li@linux.alibaba.com,
	edumazet@google.com, gbayer@linux.ibm.com,
	guwen@linux.alibaba.com, jaka@linux.ibm.com, kuba@kernel.org,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	netdev@vger.kernel.org, pabeni@redhat.com,
	syzbot+f69bfae0a4eb29976e44@syzkaller.appspotmail.com,
	tonylu@linux.alibaba.com, wenjia@linux.ibm.com
Subject: Re: [PATCH net,v3] net/smc: prevent NULL pointer dereference in txopt_get
Date: Wed, 14 Aug 2024 16:30:02 +0900	[thread overview]
Message-ID: <75AFEC8C-C050-4AC4-AF63-0B798B040502@gmail.com> (raw)
In-Reply-To: <4eeb32b7-d750-4c39-87df-43fd8365f163@linux.alibaba.com>



> D. Wythe wrote:
> 
> 
> 
>> On 8/14/24 11:58 AM, Jeongjun Park wrote:
>> Because clcsk_*, like clcsock, is initialized during the smc init process,
>> the code was moved to prevent clcsk_* from having an address like
>> inet_sk(sk)->pinet6, thereby preventing the previously initialized values
>> ​​from being tampered with.
> 
> I don't agree with your approach, but I finally got the problem you described. In fact, the issue here is that smc_sock should also be an inet_sock, whereas currently it's just a sock. Therefore, the best solution would be to embed an inet_sock within smc_sock rather than performing this movement as you suggested.
> 
> struct smc_sock {               /* smc sock container */
>     union {
>         struct sock         sk;
>         struct inet_sock    inet;
>     };
> 
>     ...
> 
> Thanks.
> D. Wythe
> 

Wow, I didn't know this could be done this way. I'll test it with that code 
and get back to you

Regards,
Jeongjun Park

> 
>> 
>> Additionally, if you don't need alignment in smc_inet6_prot , I'll modify
>> the patch to only add the necessary code without alignment.
>> 
>> Regards,
>> Jeongjun Park
> 
> 
>>> 
>>>> Also, regarding alignment, it's okay for me whether it's aligned or
>>>> not,But I checked the styles of other types of
>>>> structures and did not strictly require alignment, so I now feel that
>>>> there is no need to
>>>> modify so much to do alignment.
>>>> 
>>>> D. Wythe
>>> 
>>> 
>>>>>>> +
>>>>>>>    static struct proto smc_inet6_prot = {
>>>>>>> -     .name           = "INET6_SMC",
>>>>>>> -     .owner          = THIS_MODULE,
>>>>>>> -     .init           = smc_inet_init_sock,
>>>>>>> -     .hash           = smc_hash_sk,
>>>>>>> -     .unhash         = smc_unhash_sk,
>>>>>>> -     .release_cb     = smc_release_cb,
>>>>>>> -     .obj_size       = sizeof(struct smc_sock),
>>>>>>> -     .h.smc_hash     = &smc_v6_hashinfo,
>>>>>>> -     .slab_flags     = SLAB_TYPESAFE_BY_RCU,
>>>>>>> +     .name                           = "INET6_SMC",
>>>>>>> +     .owner                          = THIS_MODULE,
>>>>>>> +     .init                           = smc_inet_init_sock,
>>>>>>> +     .hash                           = smc_hash_sk,
>>>>>>> +     .unhash                         = smc_unhash_sk,
>>>>>>> +     .release_cb                     = smc_release_cb,
>>>>>>> +     .obj_size                       = sizeof(struct smc6_sock),
>>>>>>> +     .h.smc_hash                     = &smc_v6_hashinfo,
>>>>>>> +     .slab_flags                     = SLAB_TYPESAFE_BY_RCU,
>>>>>>> +     .ipv6_pinfo_offset              = offsetof(struct smc6_sock,
>>>>>>> np),
>>>>>>>    };
>>>>>>> 
>>>>>>>    static const struct proto_ops smc_inet6_stream_ops = {
>>>>>>> --
> 

  reply	other threads:[~2024-08-14  7:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-13 10:07 [PATCH net,v3] net/smc: prevent NULL pointer dereference in txopt_get Jeongjun Park
2024-08-13 11:11 ` D. Wythe
2024-08-13 11:37 ` D. Wythe
2024-08-13 11:48   ` Jeongjun Park
2024-08-14  2:25     ` D. Wythe
2024-08-14  2:42       ` D. Wythe
2024-08-14  3:58         ` Jeongjun Park
2024-08-14  6:00           ` D. Wythe
2024-08-14  7:30             ` Jeongjun Park [this message]
2024-08-14 10:37             ` Jeongjun Park

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=75AFEC8C-C050-4AC4-AF63-0B798B040502@gmail.com \
    --to=aha310510@gmail.com \
    --cc=alibuda@linux.alibaba.com \
    --cc=davem@davemloft.net \
    --cc=dust.li@linux.alibaba.com \
    --cc=edumazet@google.com \
    --cc=gbayer@linux.ibm.com \
    --cc=guwen@linux.alibaba.com \
    --cc=jaka@linux.ibm.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=syzbot+f69bfae0a4eb29976e44@syzkaller.appspotmail.com \
    --cc=tonylu@linux.alibaba.com \
    --cc=wenjia@linux.ibm.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