All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zheyu Ma <zheyuma97@gmail.com>
To: Jiri Slaby <jirislaby@kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	linux-serial@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4] tty: serial: jsm: allocate queue buffer at probe time
Date: Wed, 7 Jul 2021 20:28:12 +0800	[thread overview]
Message-ID: <CAMhUBj=Vrwd__fmTmegqU22Hn3zGE_iitF0+zAAkQFHssy3gaA@mail.gmail.com> (raw)
In-Reply-To: <fde46fee-fad9-8f3b-79b0-ad426fd379dd@kernel.org>

On Wed, Jul 7, 2021 at 3:49 PM Jiri Slaby <jirislaby@kernel.org> wrote:
>
> On 05. 07. 21, 14:53, Zheyu Ma wrote:
> > In function 'neo_intr', the driver uses 'ch->ch_equeue' and
> > 'ch->ch_reuque'. These two pointers are initialized in 'jsm_tty_open',
> > but the interrupt handler 'neo_intr' has been registered in the probe
> > progress. If 'jsm_tty_open' has not been called at this time, it will
> > cause null pointer dereference.
> >
> > Once the driver registers the interrupt handler, the driver should be
> > ready to handle it.
> >
> > Fix this by allocating the memory at probe time and not at open time.
>
> You are allocating the buffer in jsm_tty_init now. But that is still
> called after request_irq() in probe. So care to explain how this helps
> exactly? As I understand it, you only made the window much smaller.

You are right, this may indeed still cause problems, I did not
consider this before. So maybe we should put request_irq() at the end
of the probe function.

> Anyway, I'm no expert on jsm, but AFAICS jsm_tty_open first allocates
> the buffers, brd->bd_ops->uart_init() / neo_uart_init() clears ier and
> only brd->bd_ops->param() / neo_param() enables interrupts on the device
> (by ier update and write). So how it comes an interrupt came before
> neo_param() in jsm_tty_open was called?

I considered the threat from a malicious device, which means that a
harmful peripheral may not comply with the driver's convention,
arbitrary send interrupt signals, or send malicious data. I think the
driver should also handle this situation, at least to prevent the
kernel from crashing.

Thanks,

Zheyu Ma

  reply	other threads:[~2021-07-07 12:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-05 12:53 [PATCH v4] tty: serial: jsm: allocate queue buffer at probe time Zheyu Ma
2021-07-07  7:49 ` Jiri Slaby
2021-07-07 12:28   ` Zheyu Ma [this message]
2021-07-07 12:52   ` Andy Shevchenko
2021-07-07 19:13     ` Jiri Slaby
2021-07-09 14:00       ` Zheyu Ma
2021-07-09 14:20         ` Greg Kroah-Hartman
2021-07-09 14:55           ` Zheyu Ma
     [not found] ` <CAHp75Vdne2fVAdmMYPn71T8LnSNMxVhBVK8dbmMASTSTUnOjBA@mail.gmail.com>
2021-07-07 10:37   ` Zheyu Ma

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='CAMhUBj=Vrwd__fmTmegqU22Hn3zGE_iitF0+zAAkQFHssy3gaA@mail.gmail.com' \
    --to=zheyuma97@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.