linux-kernel - Re: [PATCH] remoteproc: error on kick missing

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANLsYkyDsJaxO_37qTjEP+aeQju8W2+jhHFRF7+oifBMqJqyng@mail.gmail.com>
Date:   Mon, 2 Mar 2020 10:44:56 -0700
From:   Mathieu Poirier <mathieu.poirier@...aro.org>
To:     nikita.shubin@...uefel.me
Cc:     Nikita Shubin <NShubin@...con.com>,
        Ohad Ben-Cohen <ohad@...ery.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        linux-remoteproc <linux-remoteproc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] remoteproc: error on kick missing

Hi Nikita,

On Fri, 28 Feb 2020 at 04:07, <nikita.shubin@...uefel.me> wrote:
>
> From: Nikita Shubin <NShubin@...con.com>
>
> .kick method not set in rproc_ops will result in:
>
> 8<--- cut here ---
> Unable to handle kernel NULL pointer dereference
>
> in rproc_virtio_notify, after firmware loading.

There wasn't any kernel stack trace?  What platform was this observed
on? I'm afraid we won't be able to move forward with this patch
without one, or more information on what is happening.

>
> refuse to register an rproc-induced virtio device if no kick method was
> defined for rproc.
>
> Signed-off-by: Nikita Shubin <NShubin@...con.com>
> ---
>  drivers/remoteproc/remoteproc_virtio.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c
> index 8c07cb2ca8ba..31a62a0b470e 100644
> --- a/drivers/remoteproc/remoteproc_virtio.c
> +++ b/drivers/remoteproc/remoteproc_virtio.c
> @@ -334,6 +334,13 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
>         struct rproc_mem_entry *mem;
>         int ret;
>
> +       if (rproc->ops->kick == NULL) {
> +               ret = -EINVAL;
> +               dev_err(dev, ".kick method not defined for %s",
> +                               rproc->name);
> +               goto out;
> +       }

I think it would be better to use WARN_ONCE() in rproc_virtio_notify()
than prevent a virtio device from being added.  But again I will need
more information on this case to know for sure.

Thanks,
Mathieu

> +
>         /* Try to find dedicated vdev buffer carveout */
>         mem = rproc_find_carveout_by_name(rproc, "vdev%dbuffer", rvdev->index);
>         if (mem) {
> --
> 2.24.1
>