Signed-off-by: Stefan Bader <email address hidden>
d141a3e...
by
Andrey Konovalov <email address hidden>
net/packet: fix overflow in check for tp_reserve
When calculating po->tp_hdrlen + po->tp_reserve the result can overflow.
Fix by checking that tp_reserve <= INT_MAX on assign.
Signed-off-by: Andrey Konovalov <email address hidden>
Acked-by: Eric Dumazet <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
BugLink: https://bugs.launchpad.net/bugs/1678009
CVE-2017-7308
(cherry picked from commit bcc5364bdcfe131e6379363f089e7b4108d35b70 linux-net)
Signed-off-by: Andy Whitcroft <email address hidden>
f6c1609...
by
Andrey Konovalov <email address hidden>
net/packet: fix overflow in check for tp_frame_nr
When calculating rb->frames_per_block * req->tp_block_nr the result
can overflow.
Add a check that tp_block_size * tp_block_nr <= UINT_MAX.
Since frames_per_block <= tp_block_size, the expression would
never overflow.
Signed-off-by: Andrey Konovalov <email address hidden>
Acked-by: Eric Dumazet <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
BugLink: https://bugs.launchpad.net/bugs/1678009
CVE-2017-7308
(cherry picked from commit 8f8d28e4d6d815a391285e121c3a53a0b6cb9e7b linux-net)
Signed-off-by: Andy Whitcroft <email address hidden>
5fefcc0...
by
Andrey Konovalov <email address hidden>
net/packet: fix overflow in check for priv area size
Subtracting tp_sizeof_priv from tp_block_size and casting to int
to check whether one is less then the other doesn't always work
(both of them are unsigned ints).
Compare them as is instead.
Also cast tp_sizeof_priv to u64 before using BLK_PLUS_PRIV, as
it can overflow inside BLK_PLUS_PRIV otherwise.
Signed-off-by: Andrey Konovalov <email address hidden>
Acked-by: Eric Dumazet <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
BugLink: https://bugs.launchpad.net/bugs/1678009
CVE-2017-7308
(cherry picked from commit 2b6867c2ce76c596676bec7d2d525af525fdc6e2 linux-net)
Signed-off-by: Andy Whitcroft <email address hidden>
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>
