tree 505fc30bcce800be63fbd2b79d3c6e9a0aaf2749
parent f99de0a97d983a6f69e7395ef8373d8ada1285a5
author Andy Whitcroft <apw@canonical.com> 1490167771 +0000
committer Mark Salyzyn <salyzyn@google.com> 1490374289 -0700

xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL replay_window

When a new xfrm state is created during an XFRM_MSG_NEWSA call we validate
the user supplied replay_esn to ensure that the size is valid and to ensure
that the replay_window size is within the allocated buffer.  However later
it is possible to update this replay_esn via a XFRM_MSG_NEWAE call.
There we again validate the size of the supplied buffer matches the
existing state and if so inject the contents.  We do not at this point
check that the replay_window is within the allocated memory.  This leads
to out-of-bounds reads and writes triggered by netlink packets.  This leads
to memory corruption and the potential for priviledge escalation.

We already attempt to validate the incoming replay information in
xfrm_new_ae() via xfrm_replay_verify_len().  This confirms that the
user is not trying to change the size of the replay state buffer which
includes the replay_esn.  It however does not check the replay_window
remains within that buffer.  Add validation of the contained replay_window.

Additionally Kees Cook has pointed out that xfrm_replay_state_esn_len()
is subject to wrapping issues.  To ensure we are correctly ensuring that
the two ESN structures are the same size compare both the overall size
as reported by xfrm_replay_state_esn_len() and the internal length are
the same.

CVE-2017-7184
ZDI-CAN-4586
Bug: 36565222
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Change-Id: I50d2766ab19fb182a5e75adf9e46ff043f2d99ea