public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vasily Averin <vvs@sw.ru>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	devel@openvz.org, Markus Lidel <Markus.Lidel@shadowconnect.com>
Subject: Re: [Devel] [patch i2o 5/6] i2o_proc files permission
Date: Tue, 15 May 2007 16:59:49 +0400	[thread overview]
Message-ID: <4649AEC5.1060501@sw.ru> (raw)
In-Reply-To: <4649ABC9.6020605@sw.ru>

I would add:
I've reported about this issue some time ago to security@kernel.org
How this lockup can be reproduced:
- boot the kernel,
- load i2o_proc module
- login as user and read all entries in /proc/i2o/ directory

My testnode hangs when I try to read any file from /proc/i2o/iop0/030/
directory: I have the shell prompt and even can try to start any new command
which hangs due exec is not works.
Node is pingable, but I cannot login to it nor via ssh neither from local
console. Magic Sysrq keys are works. Kernel space software watchdog module
works OK. But all the new commnds hangs, looks like i2o controller is in coma.

Greg KH wrote:
And I'd classify this a "low" security issue, as you have to be root to
load the i2o_proc module, and I doubt that the distros automatically
load it.

Markus Lidel:
The problem is not really driver related, IIRC. The driver properly send
a I2O command to the controller, but this one couldn't handle it and
instead of just aborting the command "panic's". IIRC it's only Adaptec
related, the Promise controllers doesn't show this behaviour.

Thank you,
	Vasily Averin

Vasily Averin wrote:
> Reading from some i2o related proc files can lead to the i2o controller hang due
> unknown reasons. As a workaround this patch changes the permission of these
> files to root-only accessible.
> 
> Signed-off-by: Vasily Averin <vvs@sw.ru>
> 
> --- lk2.6/drivers/message/i2o/i2o_proc.c
> +++ lk2.6/drivers/message/i2o/i2o_proc.c
> @@ -1855,17 +1855,17 @@ static i2o_proc_entry i2o_proc_generic_i
>   * Device specific entries
>   */
>  static i2o_proc_entry generic_dev_entries[] = {
> -	{"groups", S_IFREG | S_IRUGO, &i2o_seq_fops_groups},
> -	{"phys_dev", S_IFREG | S_IRUGO, &i2o_seq_fops_phys_device},
> -	{"claimed", S_IFREG | S_IRUGO, &i2o_seq_fops_claimed},
> -	{"users", S_IFREG | S_IRUGO, &i2o_seq_fops_users},
> -	{"priv_msgs", S_IFREG | S_IRUGO, &i2o_seq_fops_priv_msgs},
> -	{"authorized_users", S_IFREG | S_IRUGO, &i2o_seq_fops_authorized_users},
> -	{"dev_identity", S_IFREG | S_IRUGO, &i2o_seq_fops_dev_identity},
> -	{"ddm_identity", S_IFREG | S_IRUGO, &i2o_seq_fops_ddm_identity},
> -	{"user_info", S_IFREG | S_IRUGO, &i2o_seq_fops_uinfo},
> -	{"sgl_limits", S_IFREG | S_IRUGO, &i2o_seq_fops_sgl_limits},
> -	{"sensors", S_IFREG | S_IRUGO, &i2o_seq_fops_sensors},
> +	{"groups", S_IFREG | S_IRUSR, &i2o_seq_fops_groups},
> +	{"phys_dev", S_IFREG | S_IRUSR, &i2o_seq_fops_phys_device},
> +	{"claimed", S_IFREG | S_IRUSR, &i2o_seq_fops_claimed},
> +	{"users", S_IFREG | S_IRUSR, &i2o_seq_fops_users},
> +	{"priv_msgs", S_IFREG | S_IRUSR, &i2o_seq_fops_priv_msgs},
> +	{"authorized_users", S_IFREG | S_IRUSR, &i2o_seq_fops_authorized_users},
> +	{"dev_identity", S_IFREG | S_IRUSR, &i2o_seq_fops_dev_identity},
> +	{"ddm_identity", S_IFREG | S_IRUSR, &i2o_seq_fops_ddm_identity},
> +	{"user_info", S_IFREG | S_IRUSR, &i2o_seq_fops_uinfo},
> +	{"sgl_limits", S_IFREG | S_IRUSR, &i2o_seq_fops_sgl_limits},
> +	{"sensors", S_IFREG | S_IRUSR, &i2o_seq_fops_sensors},
>  	{NULL, 0, NULL}
>  };
> 
> _______________________________________________
> Devel mailing list
> Devel@openvz.org
> https://openvz.org/mailman/listinfo/devel
> 


  reply	other threads:[~2007-05-15 13:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-15 12:41 [patch i2o] i2o layer cleanup Vasily Averin
2007-05-15 12:42 ` [patch i2o 1/6] i2o_cfg_passthru cleanup Vasily Averin
2007-05-15 16:42   ` Alan Cox
2007-05-15 12:43 ` [patch i2o 2/6] wrong memory access in i2o_block_device_lock() Vasily Averin
2007-05-15 12:44 ` [patch i2o 3/6] i2o message leak in i2o_msg_post_wait_mem() Vasily Averin
2007-05-15 12:45 ` [patch i2o 4/6] i2o proc reading oops Vasily Averin
2007-05-15 12:47 ` [patch i2o 5/6] i2o_proc files permission Vasily Averin
2007-05-15 12:59   ` Vasily Averin [this message]
2007-05-16  9:27     ` [Devel] " Greg KH
2007-05-15 16:45   ` Alan Cox
2007-05-16  4:58     ` Vasily Averin
2007-05-16 12:52       ` Alan Cox
2007-05-15 12:48 ` [patch i2o 6/6] i2o debug output cleanup Vasily Averin
2007-05-15 16:46   ` Alan Cox
2007-05-15 12:53 ` [Devel] [patch i2o] i2o layer cleanup Kirill Korotaev

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=4649AEC5.1060501@sw.ru \
    --to=vvs@sw.ru \
    --cc=Markus.Lidel@shadowconnect.com \
    --cc=akpm@linux-foundation.org \
    --cc=devel@openvz.org \
    --cc=linux-kernel@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