aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorLin, Zhenpeng <zplin@psu.edu>2021-09-08 03:40:59 +0000
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2021-09-22 12:27:56 +0200
commit6c3cb65d561e76fd0398026c023e587fec70e188 (patch)
tree48698ddc55abb54afd49abbf71f93d84a6f359c1
parentf6f80766558b72d59bd7a25519abc55c71c126c7 (diff)
downloadkernel_replicant_linux-6c3cb65d561e76fd0398026c023e587fec70e188.tar.gz
kernel_replicant_linux-6c3cb65d561e76fd0398026c023e587fec70e188.tar.bz2
kernel_replicant_linux-6c3cb65d561e76fd0398026c023e587fec70e188.zip
dccp: don't duplicate ccid when cloning dccp sock
commit d9ea761fdd197351890418acd462c51f241014a7 upstream. Commit 2677d2067731 ("dccp: don't free ccid2_hc_tx_sock ...") fixed a UAF but reintroduced CVE-2017-6074. When the sock is cloned, two dccps_hc_tx_ccid will reference to the same ccid. So one can free the ccid object twice from two socks after cloning. This issue was found by "Hadar Manor" as well and assigned with CVE-2020-16119, which was fixed in Ubuntu's kernel. So here I port the patch from Ubuntu to fix it. The patch prevents cloned socks from referencing the same ccid. Fixes: 2677d2067731410 ("dccp: don't free ccid2_hc_tx_sock ...") Signed-off-by: Zhenpeng Lin <zplin@psu.edu> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-rw-r--r--net/dccp/minisocks.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/net/dccp/minisocks.c b/net/dccp/minisocks.c
index c5c74a34d139..91e7a2202697 100644
--- a/net/dccp/minisocks.c
+++ b/net/dccp/minisocks.c
@@ -94,6 +94,8 @@ struct sock *dccp_create_openreq_child(const struct sock *sk,
newdp->dccps_role = DCCP_ROLE_SERVER;
newdp->dccps_hc_rx_ackvec = NULL;
newdp->dccps_service_list = NULL;
+ newdp->dccps_hc_rx_ccid = NULL;
+ newdp->dccps_hc_tx_ccid = NULL;
newdp->dccps_service = dreq->dreq_service;
newdp->dccps_timestamp_echo = dreq->dreq_timestamp_echo;
newdp->dccps_timestamp_time = dreq->dreq_timestamp_time;