linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre SIMON <Alexandre.Simon@univ-lorraine.fr>
To: Satoru Takeuchi <satoru.takeuchi@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	Alexandre SIMON <Alexandre.Simon@univ-lorraine.fr>
Subject: Re: [ 1/1] printk: fix buffer overflow when calling log_prefix function from call_console_drivers
Date: Wed, 20 Feb 2013 14:43:09 +0100	[thread overview]
Message-ID: <5124D2ED.1090703@univ-lorraine.fr> (raw)
In-Reply-To: <87ip5njfze.wl%satoru.takeuchi@gmail.com>

[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 !


>> -			cur_index += log_prefix(&LOG_BUF(cur_index), &msg_level, NULL);
> 
> Here is one example of the problematic case.
> 
>   +---- start of log_buf
>   |
>   |                           +--- end of log_buf
>   |                           |
>   v                           v
>   <-------- log_buf ----------><------- * outside of log_buf. Don't access here !!! * --- ~~~
>                               ^
>                               |
>                               cur_index
> 
> 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.


[...]
>> +			/*
>> +			 * prepare buf_prefix, as a contiguous array,
>> +			 * to be processed by log_prefix function
>> +			 */
>> +			char buf_prefix[SYSLOG_PRI_MAX_LENGTH+1];
>> +			unsigned i;
>> +			for (i = 0; i < ((end - cur_index)) && (i < SYSLOG_PRI_MAX_LENGTH); i++) {
> 
> The condition, "i < ((end - cur_index)) && (i < SYSLOG_PRI_MAX_LENGTH)", is to prevent
> access over
> 
>  - the region to write out, and

  Yes, because buf_prefix has a fixed length.


>  - the max length of log_prefix.

  In another term : to do not exceed the end boundary of "log_buf".


> In addition, "min(end - cur_index, SYSLOG_PRI_MAX_LENGTH)" has the same meaning here.

  Yes, that may also work.


>> +				buf_prefix[i] = LOG_BUF(cur_index + i);
> 
> You ensure that all characters (not only first character) in the candidate of log_prefix
> are inside of log_buf here by copying each character of them one by one.

  Yes, I also take care of the index that must be masked to wrap around the log_buf : we restart at index=0 when cur_index > length(log_buf).
  At this point, we are sure that the buffer passed to log_prefix is consistent and all the access (through p[1], p[2], simple_strtoul(...)) may not cause a buffer overflow.


> Thanks,
> Satoru

  Bye, Alex.


  reply	other threads:[~2013-02-20 13:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-18 18:24 [ 0/1] 3.4.33-stable review Greg Kroah-Hartman
2013-02-18 18:24 ` [ 1/1] printk: fix buffer overflow when calling log_prefix function from call_console_drivers Greg Kroah-Hartman
2013-02-20 13:02   ` Satoru Takeuchi
2013-02-20 13:43     ` Alexandre SIMON [this message]
2013-02-20 15:56       ` Satoru Takeuchi
2013-02-19  2:50 ` [ 0/1] 3.4.33-stable review Shuah Khan
2013-02-20  2:51   ` Greg Kroah-Hartman
2013-02-20  3:31     ` Shuah Khan
2013-02-20 13:09       ` Satoru Takeuchi
2013-02-18 18:25 [ 0/1] 3.0.66-stable review Greg Kroah-Hartman
2013-02-18 18:25 ` [ 1/1] printk: fix buffer overflow when calling log_prefix function from call_console_drivers Greg Kroah-Hartman

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=5124D2ED.1090703@univ-lorraine.fr \
    --to=alexandre.simon@univ-lorraine.fr \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=satoru.takeuchi@gmail.com \
    --cc=stable@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).