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.