netdev - Re: [RFC][PATCH] xfrm: do not leak ESRCH to user space

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: <20081023.141158.179712309.davem@davemloft.net>
Date:	Thu, 23 Oct 2008 14:11:58 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	fernando@....ntt.co.jp
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC][PATCH] xfrm: do not leak ESRCH to user space

From: Fernando Luis Vázquez Cao <fernando@....ntt.co.jp>
Date: Thu, 23 Oct 2008 23:27:19 +0900

> I noticed that, under certain conditions, ESRCH can be leaked from the
> xfrm layer to user space through sys_connect. In particular, this seems
> to happen reliably when the kernel fails to resolve a template either
> because the AF_KEY receive buffer being used by racoon is full or
> because the SA entry we are trying to use is in XFRM_STATE_EXPIRED
> state.
> 
> However, since this could be a transient issue it could be argued that
> EAGAIN would be more appropriate. Besides this error code is not even
> documented in the man page for sys_connect (as of man-pages 3.07).
> 
> What is the expected behavior (I could not find anything in the RFCs)?
> Should we just fix the connect(2) man page instead?

I think this case requires some care.

-EAGAIN tells the caller that it is a temporary failure and that
retrying can be expected to succeed eventually (some resource is not
available at the moment).  So applications loop when they see this
error returned, they will try again.

But that's not what is happening when ESRCH is signalled.  We found
no matching policy, and we've done nothing to make such a policy
be found in the (near) future.  It is more of a hard failure, which
should not necessarily be retried over and over again.

So converting this to -EAGAIN doesn't seem correct at all.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html