Linux v4.10.5
This commit is contained in:
Justin M. Forbes
parent
39bd1a1488
commit
9f7a0c0e77
|
|
@ -0,0 +1 @@
|
|||
CONFIG_QCOM_QDF2400_ERRATUM_0065=y
|
||||
|
|
@ -4026,6 +4026,7 @@ CONFIG_QCOM_GSBI=y
|
|||
CONFIG_QCOM_HIDMA=m
|
||||
CONFIG_QCOM_HIDMA_MGMT=m
|
||||
# CONFIG_QCOM_Q6V5_PIL is not set
|
||||
CONFIG_QCOM_QDF2400_ERRATUM_0065=y
|
||||
CONFIG_QCOM_QFPROM=m
|
||||
CONFIG_QCOM_SMD=m
|
||||
CONFIG_QCOM_SMD_RPM=m
|
||||
|
|
|
|||
|
|
@ -4004,6 +4004,7 @@ CONFIG_QCOM_GSBI=y
|
|||
CONFIG_QCOM_HIDMA=m
|
||||
CONFIG_QCOM_HIDMA_MGMT=m
|
||||
# CONFIG_QCOM_Q6V5_PIL is not set
|
||||
CONFIG_QCOM_QDF2400_ERRATUM_0065=y
|
||||
CONFIG_QCOM_QFPROM=m
|
||||
CONFIG_QCOM_SMD=m
|
||||
CONFIG_QCOM_SMD_RPM=m
|
||||
|
|
|
|||
10
kernel.spec
10
kernel.spec
|
|
@ -54,7 +54,7 @@ Summary: The Linux kernel
|
|||
%if 0%{?released_kernel}
|
||||
|
||||
# Do we have a -stable update to apply?
|
||||
%define stable_update 4
|
||||
%define stable_update 5
|
||||
# Set rpm version accordingly
|
||||
%if 0%{?stable_update}
|
||||
%define stablerev %{stable_update}
|
||||
|
|
@ -608,8 +608,8 @@ Patch853: 0001-Work-around-for-gcc7-and-arm64.patch
|
|||
#CVE-2017-2596 rhbz 1417812 1417813
|
||||
Patch854: kvm-fix-page-struct-leak-in-handle_vmon.patch
|
||||
|
||||
#CVE-2017-6353 rhbz 1428907 1428910
|
||||
Patch855: sctp-deny-peeloff-operation-on-asocs-with-threads-sl.patch
|
||||
#Fix crda rhbz 1422247
|
||||
Patch856: genetlink-fix-counting-regression-on-ctrl_dumpfamily.patch
|
||||
|
||||
# END OF PATCH DEFINITIONS
|
||||
|
||||
|
|
@ -2180,6 +2180,10 @@ fi
|
|||
#
|
||||
#
|
||||
%changelog
|
||||
* Wed Mar 22 2017 Justin M. Forbes <jforbes@fedoraproject.org> - 4.10.5-200
|
||||
- Linux v4.10.5
|
||||
- Fix crda (rhbz 1422247)
|
||||
|
||||
* Mon Mar 20 2017 Justin M. Forbes <jforbes@fedoraproject.org> - 4.10.4-200
|
||||
- Linux v4.10.4
|
||||
|
||||
|
|
|
|||
|
|
@ -1,66 +0,0 @@
|
|||
From dfcb9f4f99f1e9a49e43398a7bfbf56927544af1 Mon Sep 17 00:00:00 2001
|
||||
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
|
||||
Date: Thu, 23 Feb 2017 09:31:18 -0300
|
||||
Subject: [PATCH] sctp: deny peeloff operation on asocs with threads sleeping
|
||||
on it
|
||||
|
||||
commit 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
|
||||
attempted to avoid a BUG_ON call when the association being used for a
|
||||
sendmsg() is blocked waiting for more sndbuf and another thread did a
|
||||
peeloff operation on such asoc, moving it to another socket.
|
||||
|
||||
As Ben Hutchings noticed, then in such case it would return without
|
||||
locking back the socket and would cause two unlocks in a row.
|
||||
|
||||
Further analysis also revealed that it could allow a double free if the
|
||||
application managed to peeloff the asoc that is created during the
|
||||
sendmsg call, because then sctp_sendmsg() would try to free the asoc
|
||||
that was created only for that call.
|
||||
|
||||
This patch takes another approach. It will deny the peeloff operation
|
||||
if there is a thread sleeping on the asoc, so this situation doesn't
|
||||
exist anymore. This avoids the issues described above and also honors
|
||||
the syscalls that are already being handled (it can be multiple sendmsg
|
||||
calls).
|
||||
|
||||
Joint work with Xin Long.
|
||||
|
||||
Fixes: 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
|
||||
Cc: Alexander Popov <alex.popov@linux.com>
|
||||
Cc: Ben Hutchings <ben@decadent.org.uk>
|
||||
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
|
||||
Signed-off-by: Xin Long <lucien.xin@gmail.com>
|
||||
Signed-off-by: David S. Miller <davem@davemloft.net>
|
||||
---
|
||||
net/sctp/socket.c | 8 ++++++--
|
||||
1 file changed, 6 insertions(+), 2 deletions(-)
|
||||
|
||||
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
|
||||
index b532148..465a9c8 100644
|
||||
--- a/net/sctp/socket.c
|
||||
+++ b/net/sctp/socket.c
|
||||
@@ -4862,6 +4862,12 @@ int sctp_do_peeloff(struct sock *sk, sctp_assoc_t id, struct socket **sockp)
|
||||
if (!asoc)
|
||||
return -EINVAL;
|
||||
|
||||
+ /* If there is a thread waiting on more sndbuf space for
|
||||
+ * sending on this asoc, it cannot be peeled.
|
||||
+ */
|
||||
+ if (waitqueue_active(&asoc->wait))
|
||||
+ return -EBUSY;
|
||||
+
|
||||
/* An association cannot be branched off from an already peeled-off
|
||||
* socket, nor is this supported for tcp style sockets.
|
||||
*/
|
||||
@@ -7599,8 +7605,6 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p,
|
||||
*/
|
||||
release_sock(sk);
|
||||
current_timeo = schedule_timeout(current_timeo);
|
||||
- if (sk != asoc->base.sk)
|
||||
- goto do_error;
|
||||
lock_sock(sk);
|
||||
|
||||
*timeo_p = current_timeo;
|
||||
--
|
||||
2.9.3
|
||||
|
||||
2
sources
2
sources
|
|
@ -1,3 +1,3 @@
|
|||
SHA512 (linux-4.10.tar.xz) = c3690125a8402df638095bd98a613fcf1a257b81de7611c84711d315cd11e2634ab4636302b3742aedf1e3ba9ce0fea53fe8c7d48e37865d8ee5db3565220d90
|
||||
SHA512 (perf-man-4.10.tar.gz) = 2c830e06f47211d70a8330961487af73a8bc01073019475e6b6131d3bb8c95658b77ca0ae5f1b44371accf103658bc5a3a4366b3e017a4088a8fd408dd6867e8
|
||||
SHA512 (patch-4.10.4.xz) = a0631f3ee744984d9388d8e9ad98e7238d9305d94082db784b28080d9bae4f2c0cca84e4510ccfa562f5246ce1ed98c78cf41edc5a3b3bcc862ed62a1f2c8516
|
||||
SHA512 (patch-4.10.5.xz) = db494568a31cb9284f6a528f630ade1a6fdadf507187ec83ace48ccf9980663f3a636bc8a9a1d76b5beb3eb80e2e765d616898ec95d27aeee53fb4f04884c739
|
||||
|
|
|
|||
Loading…
Reference in New Issue