All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Colin King <colin.king@canonical.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>, Phil Elwell <phil@raspberrypi.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Eric Anholt <eric@anholt.net>,
	Thor Thayer <tthayer@opensource.altera.com>,
	Rafael Gago <rafael.gago@gmail.com>,
	David Lechner <david@lechnology.com>,
	linux-serial@vger.kernel.org
Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][serial-next] serial: 8250: don't dereference em485 until it has been null checked
Date: Tue, 29 Aug 2017 19:57:37 +0000	[thread overview]
Message-ID: <1504036657.25945.153.camel@linux.intel.com> (raw)
In-Reply-To: <20170829165815.23429-1-colin.king@canonical.com>

On Tue, 2017-08-29 at 17:58 +0100, Colin King wrote:

> Currently, the pointer em485 is dereferenced to get p and then later
> em485 is checked to see if it is null before calling __start_tx. In
> the case where em485 is null, we get a null pointer dereference. Fix
> this by moving the deference and the associated spinlock/unlocks on
> p to the code block where em485 is known to be not null.

>  static enum hrtimer_restart serial8250_em485_handle_start_tx(struct
> hrtimer *t)
>  {
>  	struct uart_8250_em485 *em485;
> -	struct uart_8250_port *p;
>  	unsigned long flags;
>  	em485 = container_of(t, struct uart_8250_em485,
> start_tx_timer);
> -	p = em485->port;
>  
> -	spin_lock_irqsave(&p->port.lock, flags);
>  	if (em485 &&
>  	    em485->active_timer = &em485->start_tx_timer) {
> +		struct uart_8250_port *p = em485->port;
> +
> +		spin_lock_irqsave(&p->port.lock, flags);

Can you describe, please, what on your opinion is protected by this
lock?

>  		__start_tx(&p->port);
>  		em485->active_timer = NULL;
> +		spin_unlock_irqrestore(&p->port.lock, flags);
>  	}
> -	spin_unlock_irqrestore(&p->port.lock, flags);
>  	return HRTIMER_NORESTART;
>  }
>  

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Colin King <colin.king@canonical.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>, Phil Elwell <phil@raspberrypi.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Eric Anholt <eric@anholt.net>,
	Thor Thayer <tthayer@opensource.altera.com>,
	Rafael Gago <rafael.gago@gmail.com>,
	David Lechner <david@lechnology.com>,
	linux-serial@vger.kernel.org
Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][serial-next] serial: 8250: don't dereference em485 until it has been null checked
Date: Tue, 29 Aug 2017 22:57:37 +0300	[thread overview]
Message-ID: <1504036657.25945.153.camel@linux.intel.com> (raw)
In-Reply-To: <20170829165815.23429-1-colin.king@canonical.com>

On Tue, 2017-08-29 at 17:58 +0100, Colin King wrote:

> Currently, the pointer em485 is dereferenced to get p and then later
> em485 is checked to see if it is null before calling __start_tx. In
> the case where em485 is null, we get a null pointer dereference. Fix
> this by moving the deference and the associated spinlock/unlocks on
> p to the code block where em485 is known to be not null.

>  static enum hrtimer_restart serial8250_em485_handle_start_tx(struct
> hrtimer *t)
>  {
>  	struct uart_8250_em485 *em485;
> -	struct uart_8250_port *p;
>  	unsigned long flags;
>  	em485 = container_of(t, struct uart_8250_em485,
> start_tx_timer);
> -	p = em485->port;
>  
> -	spin_lock_irqsave(&p->port.lock, flags);
>  	if (em485 &&
>  	    em485->active_timer == &em485->start_tx_timer) {
> +		struct uart_8250_port *p = em485->port;
> +
> +		spin_lock_irqsave(&p->port.lock, flags);

Can you describe, please, what on your opinion is protected by this
lock?

>  		__start_tx(&p->port);
>  		em485->active_timer = NULL;
> +		spin_unlock_irqrestore(&p->port.lock, flags);
>  	}
> -	spin_unlock_irqrestore(&p->port.lock, flags);
>  	return HRTIMER_NORESTART;
>  }
>  

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

  reply	other threads:[~2017-08-29 19:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-29 16:58 [PATCH][serial-next] serial: 8250: don't dereference em485 until it has been null checked Colin King
2017-08-29 16:58 ` Colin King
2017-08-29 19:57 ` Andy Shevchenko [this message]
2017-08-29 19:57   ` Andy Shevchenko
2017-08-29 20:04 ` Dan Carpenter
2017-08-29 20:04   ` Dan Carpenter
2017-08-29 20:22   ` Andy Shevchenko
2017-08-29 20:22     ` Andy Shevchenko

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=1504036657.25945.153.camel@linux.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=colin.king@canonical.com \
    --cc=david@lechnology.com \
    --cc=eric@anholt.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jan.kiszka@siemens.com \
    --cc=jslaby@suse.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=phil@raspberrypi.org \
    --cc=rafael.gago@gmail.com \
    --cc=tthayer@opensource.altera.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 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.