public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stas Sergeev <stsp@aknet.ru>
To: linux-kernel@vger.kernel.org
Subject: Bug in IO bitmap handling? Probably exploitable (2.6.5)
Date: Fri, 07 May 2004 19:09:37 +0400	[thread overview]
Message-ID: <409BA6B1.7030809@aknet.ru> (raw)

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]


Hello.

The attached is the small program that
tries to write 0x20 to port 0x20.
Normally this should cause SIGSEGV, so
the program should crash.
I think there is a bug in the 2.6
kernels though, which makes it to not
crash if some trivial conditions are
met. Basically it seems that if any process
that obtained an IO access permissions
via ioperm(), exits without explicitly
"dropping" that permissions, the IO
permissions gets "inherited" by all
other processes in the system.
The cause seems to be that exit_thread()
only invalidates the per-thread io_bitmap
pointer, but doesn't invalidate the
per-TSS io_bitmap pointer as well. As the
per-thread pointer is invalidated,
__switch_to() doesn't take care of that
one either, so the per-TSS pointer stays
valid as long as some other process
does ioperm().
Here it is sufficient to start an X server
and exit it, and then the program that
is attached, will not get a SIGSEGV any
more, actually successing with the port
write.
I am also attaching the patch that seems
like fixing the problem - it invalidates
also the per-TSS io_bitmap pointer and
the problem goes away.

Can someone please confirm (or refute)
the presense of the bug there? Because
if it is really a bug, I suppose it can
be exploited, if not for getting root,
then at least to deadlock the machine.

[-- Attachment #2: port.c --]
[-- Type: text/plain, Size: 121 bytes --]


#include <stdio.h>
#include <asm/io.h>

int main()
{
  outb(0x20, 0x20);
  printf("Fine, I am alive!\n");
  return 0;
}

[-- Attachment #3: tss_iobtm.diff --]
[-- Type: text/plain, Size: 503 bytes --]


--- linux/arch/i386/kernel/process.c	2004-04-14 09:41:14.000000000 +0400
+++ linux/arch/i386/kernel/process.c	2004-05-07 14:54:13.000000000 +0400
@@ -293,8 +293,11 @@
 
 	/* The process may have allocated an io port bitmap... nuke it. */
 	if (unlikely(NULL != tsk->thread.io_bitmap_ptr)) {
+		int cpu = smp_processor_id();
+		struct tss_struct *tss = init_tss + cpu;
 		kfree(tsk->thread.io_bitmap_ptr);
 		tsk->thread.io_bitmap_ptr = NULL;
+		tss->io_bitmap_base = INVALID_IO_BITMAP_OFFSET;
 	}
 }
 

[-- Attachment #4: Type: text/plain, Size: 82 bytes --]


Scanned by evaluation version of Dr.Web antivirus Daemon 
http://drweb.ru/unix/


             reply	other threads:[~2004-05-07 15:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-07 15:09 Stas Sergeev [this message]
2004-05-07 16:38 ` Bug in IO bitmap handling? Probably exploitable (2.6.5) Linus Torvalds

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=409BA6B1.7030809@aknet.ru \
    --to=stsp@aknet.ru \
    --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