[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231101170506.GS4163@brightrain.aerifal.cx>
Date: Wed, 1 Nov 2023 13:05:06 -0400
From: Rich Felker <dalias@...c.org>
To: Markus Wichmann <nullplan@....net>
Cc: musl@...ts.openwall.com
Subject: Re: synccall patches
On Wed, Nov 01, 2023 at 02:53:32PM +0100, Markus Wichmann wrote:
> Am Wed, Nov 01, 2023 at 09:00:33AM -0400 schrieb Rich Felker:
> > On the other hand, the thing you're worried about, the original value
> > of c.ret being passed to __syscall_ret, can't happen. If it was
> > initially positive on entry to do_setxid, a syscall is made and the
> > return value is stored into c.ret.
> >
>
> But if the tkill fails in __synccall, do_setxid() will never be called
> at all (that's what line 87 in synccall.c does). So the original value
> will remain.
>
> Perhaps __synccall should return failure in that case, after doing
> everything else. Then the logic could otherwise remain untouched, and
> __setxid could respond appropriately to the failure itself.
OK, that failure case should not actually be reachable short of bogus
seccomp filters or kernel doing something dumb. But if it is
reachable, yes that's a bug.
The simplest fix is probably just changing the setxid logic to detect
that the callback was never called and convert that to an error. One
motivation for changing the __synccall contract to return this error
might be reporting which error it was, but I don't really see a good
reason these errors that shouldn't happen (and which might clash with
the existing meaning of error codes used by set*id) should translate
directly into error codes for the caller.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
