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
Signed-off-by: Andy Whitcroft <email address hidden>
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.
CVE-2017-7184
Signed-off-by: Andy Whitcroft <email address hidden>
Some Hypervisors detach VFs from VMs by instantly causing an FLR event
to be generated for a VF.
In the mlx4 case, this will cause that VF's comm channel to be disabled
before the VM has an opportunity to invoke the VF device's "shutdown"
method.
For such Hypervisors, there is a race condition between the VF's
shutdown method and its internal-error detection/reset thread.
The internal-error detection/reset thread (which runs every 5 seconds) also
detects a disabled comm channel. If the internal-error detection/reset
flow wins the race, we still get delays (while that flow tries repeatedly
to detect comm-channel recovery).
The cited commit fixed the command timeout problem when the
internal-error detection/reset flow loses the race.
This commit avoids the unneeded delays when the internal-error
detection/reset flow wins.
The recent changes that added SMB3 encryption support introduced
a possible use after free in the demultiplex thread. When we
process an encrypted packed we obtain a pointer to SMB session
but do not obtain a reference. This can possibly lead to a situation
when this session was freed before we copy a decryption key from
there. Fix this by obtaining a copy of the key rather than a pointer
to the session under a spinlock.
Signed-off-by: Pavel Shilovsky <email address hidden>
Signed-off-by: Steve French <email address hidden>
(cherry picked from commit 61cfac6f267dabcf2740a7ec8a0295833b28b5f5)
Acked-by: Brad Figg <email address hidden>
Signed-off-by: Marcelo Henrique Cerri <email address hidden>
Allow to decrypt transformed packets that are bigger than the big
buffer size. In particular it is used for read responses that can
only exceed the big buffer size.
