linux-kernel - Re: [PATCH][BUG] Fix possible NULL pointer access in 8250 serial driver

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] [day] [month] [year] [list]

Message-Id: <20070418220812.b809c8fb.akpm@linux-foundation.org>
Date:	Wed, 18 Apr 2007 22:08:12 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	izumi <izumi2005@...t.fujitsu.com>
Cc:	Russell King <rmk+lkml@....linux.org.uk>,
	linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
	kaneshige.kenji@...fujitsu.com
Subject: Re: [PATCH][BUG] Fix possible NULL pointer access in 8250 serial
 driver

On Thu, 19 Apr 2007 11:28:37 +0900 izumi <izumi2005@...t.fujitsu.com> wrote:

> Russell King wrote:
> 
> > NAK.  This means that you change the list of ports available on the
> > machine to be limited to only those which are currently open.  Utterly
> > useless for debugging, where you normally want people to dump the
> > contents of /proc/tty/driver/*.
> > 
> > The original patch was better.
> > 
> 
>    Is the original patch sufficient?  or is there anything we should 
> correct?
> 

Would it be better to do something like

--- a/drivers/serial/serial_core.c~a
+++ a/drivers/serial/serial_core.c
@@ -1686,9 +1686,12 @@ static int uart_line_info(char *buf, str
 		pm_state = state->pm_state;
 		if (pm_state)
 			uart_change_pm(state, 0);
-		spin_lock_irq(&port->lock);
-		status = port->ops->get_mctrl(port);
-		spin_unlock_irq(&port->lock);
+		status = 0;
+		if (port->info) {
+			spin_lock_irq(&port->lock);
+			status = port->ops->get_mctrl(port);
+			spin_unlock_irq(&port->lock);
+		}
 		if (pm_state)
 			uart_change_pm(state, pm_state);
 		mutex_unlock(&state->mutex);
_

so that a) we treat all uart types in the same way and b) the same problem
doesn't occur later with some other driver which is assuming an opened
device in its ->get_mctrl() handler?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/