All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jordi Brinquez <jordi.brinquez@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: Possible bug on signal.h
Date: Thu, 24 Feb 2005 15:33:17 +0100	[thread overview]
Message-ID: <61d439b050224063362ab1465@mail.gmail.com> (raw)

Hi,

I think I found a possible bug on file signal.h.

The problem comes when you define a struct sigaction on a user program
and then you use the function sigaction to remap a signal handler (in
my case a page_fault) for my own function, this system call is
compiled as __NR_sigaction system call (by default this routine is
managed by sys_sigaction routine) and if the architecture defines
__ARCH_WANT_SYS_RT_SIGACTION kernel uses the routine sys_rt_sigaction
on the file kernel/signal.c that instead of copying the fields from
one structure to the other it just uses copy_from_user and
copy_to_user with the consequent mess with the fields.

One possible solution will be to change the field order in all struct
sigaction under arch/ folder and reorder the fields exactly the same
as in the kernel definition (on kernel mode are defined in this order
sa_handler, sa_flags, sa_restorer, sa_mask and on user mode
_sa_handler | _sa_sigaction, sa_mask, sa_flags, sa_restorer).

Another solution will be change the copy_to_user and copy_from_user
for calls like in arch/i386/kernel/signal.c (__get_user(...) and
__put_user(...)).

Or what I think it will be better change both.

I've been searching and I think that the affected architectures are
those ones, but I may forgot some:

- arm
- arm26
- cris
- i386
- m32r
- m68k
- m68knommu
- s390
- sh
- sh64
- sparc64
- um
- v850

Hope I explained the problem quite clear if not please ask for more
info and I'll give you all that you need.

Greets,

Jordi

             reply	other threads:[~2005-02-24 14:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-24 14:33 Jordi Brinquez [this message]
2005-02-24 15:01 ` Possible bug on signal.h linux-os
2005-02-25  0:04   ` Jordi Brínquez

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=61d439b050224063362ab1465@mail.gmail.com \
    --to=jordi.brinquez@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.