linux-kernel - Re: [PATCH] signalfd: fill in ssi_int for posix timers and message queues

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1007051121150.26563@makko.or.mcafeemobile.com>
Date:	Mon, 5 Jul 2010 11:23:13 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Nathan Lynch <ntl@...ox.com>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] signalfd: fill in ssi_int for posix timers and message
 queues

On Mon, 5 Jul 2010, Nathan Lynch wrote:

> Hello Davide,
> 
> On Sat, 2010-07-03 at 12:09 -0700, Davide Libenzi wrote:
> > On Fri, 2 Jul 2010, Nathan Lynch wrote:
> > 
> > > If signalfd is used to consume a signal generated by a POSIX interval
> > > timer or POSIX message queue, the ssi_int field does not reflect the
> > > data (sigevent->sigev_value) supplied to timer_create(2) or
> > > mq_notify(3).  (The ssi_ptr field, however, is filled in.)
> > > 
> > > This behavior differs from signalfd's treatment of sigqueue-generated
> > > signals -- see the default case in signalfd_copyinfo.  It also gives
> > > results that differ from the case when a signal is handled
> > > conventionally via a sigaction-registered handler.
> > > 
> > > So, set signalfd_siginfo->ssi_int in the remaining cases (__SI_TIMER,
> > > __SI_MESGQ) where ssi_ptr is set.
> > > 
> > > Signed-off-by: Nathan Lynch <ntl@...ox.com>
> > > ---
> > >  fs/signalfd.c |    2 ++
> > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/fs/signalfd.c b/fs/signalfd.c
> > > index f329849..1c5a6ad 100644
> > > --- a/fs/signalfd.c
> > > +++ b/fs/signalfd.c
> > > @@ -88,6 +88,7 @@ static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo,
> > >  		 err |= __put_user(kinfo->si_tid, &uinfo->ssi_tid);
> > >  		 err |= __put_user(kinfo->si_overrun, &uinfo->ssi_overrun);
> > >  		 err |= __put_user((long) kinfo->si_ptr, &uinfo->ssi_ptr);
> > > +		 err |= __put_user(kinfo->si_int, &uinfo->ssi_int);
> > >  		break;
> > >  	case __SI_POLL:
> > >  		err |= __put_user(kinfo->si_band, &uinfo->ssi_band);
> > > @@ -111,6 +112,7 @@ static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo,
> > >  		err |= __put_user(kinfo->si_pid, &uinfo->ssi_pid);
> > >  		err |= __put_user(kinfo->si_uid, &uinfo->ssi_uid);
> > >  		err |= __put_user((long) kinfo->si_ptr, &uinfo->ssi_ptr);
> > > +		err |= __put_user(kinfo->si_int, &uinfo->ssi_int);
> > >  		break;
> > >  	default:
> > 
> > I am fine with it, but I now noticed that signalfd_copyinfo() got out of 
> > sync from copy_siginfo_to_user(), which should match.
> > Do you mind aligning that too, as part of your patch?
> > An adding a comment on the lines of the one in copy_siginfo_to_user() to 
> > signalfd_copyinfo() too?
> 
> Sorry, I'm not sure I understand.  Are you saying that
> copy_siginfo_to_user should have analogous lines added to assign to
> si_int?  That's actually not necessary if I read the code correctly: in
> struct siginfo, si_ptr and si_int are members of a sigval union, so
> assigning to the former covers the latter.  signalfd must assign both
> ssi_ptr and ssi_int since they occupy different locations in
> signalfd_siginfo.
> 
> Perhaps the attached testcases make the problem (as I see it) more
> clear?  The final assertion fails without this patch.

Sorry, my bad.  I had forgotten that siginfo had them in a union, so the 
different code in signalfd_copyinfo() is needed.
Patch looks fine to me as is.


- Davide


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/