From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935889Ab3BTP4T (ORCPT ); Wed, 20 Feb 2013 10:56:19 -0500 Received: from mail-pb0-f41.google.com ([209.85.160.41]:37641 "EHLO mail-pb0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935689Ab3BTP4R (ORCPT ); Wed, 20 Feb 2013 10:56:17 -0500 Date: Thu, 21 Feb 2013 00:56:08 +0900 Message-ID: <871ucbgesn.wl%satoru.takeuchi@gmail.com> From: Satoru Takeuchi To: Alexandre SIMON Cc: Satoru Takeuchi , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [ 1/1] printk: fix buffer overflow when calling log_prefix function from call_console_drivers In-Reply-To: <5124D2ED.1090703@univ-lorraine.fr> References: <20130218181454.615592566@linuxfoundation.org> <20130218181454.976143076@linuxfoundation.org> <87ip5njfze.wl%satoru.takeuchi@gmail.com> <5124D2ED.1090703@univ-lorraine.fr> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.4 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Wed, 20 Feb 2013 14:43:09 +0100, Alexandre SIMON wrote: > > [Satoru Takeuchi] wrote the following on [20/02/2013 14:02]: > [...] > > > > I reviewed this patch and it seems to be good for me. Since I'm not good at > > printk code, I want to confirm whether what I think is correct or not. > > Is the following my understanding correct? > > No problem, it's nice to talk about this patch ! ... > > In this case, only LOG_BUF(cur_index) is safe to access and > > > > - "LOG_BUF(cur_index) + 1" as p[1], > > - "LOG_BUF(cur_index) + 2" as p[2], and > > - "LOG_BUF(cur_index) + 1 or more" as simple_strtoul(&p[1], &endp, 10) > > > > in log_prefix() are not to do so. Hence touching them would cause the system hang as you > > said as follows. > > Yes, your analyze is totally right. Your figure is clear and shows exactly when the problem occurs in the "borderline case". > The initial code does not check that the "cur_index" can be at the end of "log_buf" whereas "log_prefix" function may access to one, two or more indexes after. Alex, thank you for quick response and the detailed explanation. Greg, then I can say this patch looks correct and 3.0.66-rc1 version is too. Thanks, Satoru