lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE-0n51oCcb8_1No22gNy2QS=ZL=DxQLZWT9NNGNZGev+4cy8g@mail.gmail.com>
Date:   Wed, 7 Sep 2022 19:52:59 -0500
From:   Stephen Boyd <swboyd@...omium.org>
To:     Deepak Kumar Singh <quic_deesin@...cinc.com>,
        bjorn.andersson@...aro.org, mathieu.poirier@...aro.org,
        quic_clew@...cinc.com
Cc:     linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-remoteproc@...r.kernel.org
Subject: Re: [PATCH V2 1/2] rpmsg: glink: Add lock to avoid race when rpmsg
 device is released

Quoting Deepak Kumar Singh (2022-09-05 11:55:19)
> When remote host goes down glink char device channel is freed,
> At the same time user space apps can still try to open/poll rpmsg
> char device which will result in calling rpmsg_create_ept. This may
> cause reference to already freed context of glink chardev channel and
> result in below crash signatures -
>
> 1)
> rpmsg_create_ept+0x40/0xa0
> rpmsg_eptdev_open+0x88/0x138
> chrdev_open+0xc4/0x1c8
> do_dentry_open+0x230/0x378
>
> 2)
> rpmsg_poll+0x5c/0x80
> rpmsg_eptdev_poll+0x84/0xa4
> do_sys_poll+0x22c/0x5c8
>
> This patch adds proper lock and check condition to avoid such crash.

Usually it's nice to have a two CPU diagram that shows the problem
scenario with time flowing down and interleaving the calls with
indentation, instead of some callstacks. Can you add that detail here? I
guess it would look like this:

  CPU0                      CPU1
  ----                      ----
  do_sys_poll()             chrdev_open()
   rpmsg_eptdev_poll()       rpmsg_eptdev_open()
                              rpmsg_create_ept()
    rpmsg_poll()
     <access old rpdev pointer?>

but I don't immediately understand the problem. Probably showing the
free path and wherever eptdev is set to NULL will help inform better
than a parallel poll and chrdev open.

>
> Signed-off-by: Deepak Kumar Singh <quic_deesin@...cinc.com>
> ---

Any Fixes tag?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ