linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mathias Krause <minipli@googlemail.com>
To: "David S. Miller" <davem@davemloft.net>
Cc: Steffen Klassert <steffen.klassert@secunet.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Mathias Krause <minipli@googlemail.com>
Subject: [PATCH 0/6] xfrm_user info leaks
Date: Wed, 19 Sep 2012 23:33:37 +0200	[thread overview]
Message-ID: <1348090423-32665-1-git-send-email-minipli@googlemail.com> (raw)

Hi David,

the following series fixes various info leaks in the xfrm netlink
interface. As always, a test case can be supplied on request.

Patches 1 to 5 are probably material for stable, too. Patch 6 is just a
minor optimization I stumbled across while auditing the code.

Please apply!

P.S.: What's still missing IMHO, is some upper limit for the ESN replay
window size to prevent malicious users from making the kernel allocate
huge states. One could not retrieve those via netlink anyway (as the
current code allocates just a single page for the state dump). Maybe 4k
is a sane default upper limit for the replay window size. But I'll leave
implementing this to someone else. ;)


Mathias Krause (6):
  xfrm_user: fix info leak in copy_to_user_auth()
  xfrm_user: fix info leak in copy_to_user_state()
  xfrm_user: fix info leak in copy_to_user_policy()
  xfrm_user: fix info leak in copy_to_user_tmpl()
  xfrm_user: ensure user supplied esn replay window is valid
  xfrm_user: don't copy esn replay window twice for new states

 net/xfrm/xfrm_user.c |   41 ++++++++++++++++++++++++++++++-----------
 1 file changed, 30 insertions(+), 11 deletions(-)

-- 
1.7.10.4


             reply	other threads:[~2012-09-19 21:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-19 21:33 Mathias Krause [this message]
2012-09-19 21:33 ` [PATCH 1/6] xfrm_user: fix info leak in copy_to_user_auth() Mathias Krause
2012-09-19 21:33 ` [PATCH 2/6] xfrm_user: fix info leak in copy_to_user_state() Mathias Krause
2012-09-19 21:33 ` [PATCH 3/6] xfrm_user: fix info leak in copy_to_user_policy() Mathias Krause
2012-09-19 21:33 ` [PATCH 4/6] xfrm_user: fix info leak in copy_to_user_tmpl() Mathias Krause
2012-09-20  7:26   ` Steffen Klassert
2012-09-19 21:33 ` [PATCH 5/6] xfrm_user: ensure user supplied esn replay window is valid Mathias Krause
2012-09-19 22:38   ` Ben Hutchings
2012-09-20  6:12     ` Mathias Krause
2012-09-20  6:22       ` [PATCH v2] " Mathias Krause
2012-09-20  7:05       ` [PATCH 5/6] " Steffen Klassert
2012-09-20  7:37         ` Mathias Krause
2012-09-20 20:01         ` [PATCH v3 5/7] " Mathias Krause
2012-09-20  7:13       ` [PATCH 5/6] " Mathias Krause
2012-09-19 21:33 ` [PATCH 6/6] xfrm_user: don't copy esn replay window twice for new states Mathias Krause
2012-09-20  7:27   ` Steffen Klassert
2012-09-20 22:09 ` [PATCH 0/6] xfrm_user info leaks David Miller
2012-09-21  5:37   ` Mathias Krause

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=1348090423-32665-1-git-send-email-minipli@googlemail.com \
    --to=minipli@googlemail.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).