Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5635808pxb; Thu, 20 Jan 2022 01:10:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJxkuv+cbtdZ+zWCdrA3vwr4MX/o4+vkJElMZtH2g6q8UrQjLt595I3wFErIoidwQaBClJvR X-Received: by 2002:a17:90a:de8e:: with SMTP id n14mr9516402pjv.122.1642669823868; Thu, 20 Jan 2022 01:10:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642669823; cv=none; d=google.com; s=arc-20160816; b=YHafqxiLD3wPmQX66QChajSX8z4/d8+uZbRFhflPB9MmHPh1/L8HN3Y4Qcg3TZ+GOB veSVSNQe9mTtN0pCCFIrJzV4hKO//3RT7F6Dc8kiBHwpXKR3tI/AbEmoNLt9Uoj44p+Z Y/UhPDFNG5LpS82N+dQDNsZZa9t72KxkF4S4ivNishNzqsrINVT29DmAj8EkiPAPUPc3 RXLk1EBVbS0ci5u6KJjUPkvWaxOqdx3tpM76E9UeiL00QpUVJm4zOZg6Hihc/miQVckt 3PSqOZgNVo3XnAg+be3yxtr9SVsWWJzi5nlGKpGVBnJooMKM7pTySn0AdoYRO6nX5mbP P+6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=oNKSGpqaR2QVhO3C1xz5X05CqIYXVNy8gVtUU4rd8DY=; b=PJQYOHFGuYM+p38u1YVjIh3IT0FWE3Uk8PM69hd4o9CWkhCFIruk4gSH/bwYmufMfy +O/rxL0R+uVAl41G2RNlvdNC5LVrjrcuWQSa99eoZp7EbTC51bsHpz3rvH9FXfz0wCWb 6Ds6aVjc51pt81D908KzXCFhjNZZTAsXVS2Kmw4fGa5/VWKZ5IPx8XGlZPh8tvxvmtOe vaIlh/P54tOEs6za1Vl6Fkgjv3wF83KV/lGAmEDkSIFs+q4ojZdte5FMgBb/0eAyXVhm en69bOhpAXvXxIeU3mRy1BnAd1b/9NENmil7Xlwfo0odh1H96QRb1WL9fWT6tnvOpklU GeJA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 25si2663989pgm.381.2022.01.20.01.10.11; Thu, 20 Jan 2022 01:10:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238991AbiARMqr (ORCPT + 99 others); Tue, 18 Jan 2022 07:46:47 -0500 Received: from szxga08-in.huawei.com ([45.249.212.255]:31101 "EHLO szxga08-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238498AbiARMqq (ORCPT ); Tue, 18 Jan 2022 07:46:46 -0500 Received: from canpemm500006.china.huawei.com (unknown [172.30.72.57]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4JdT2V1PdJz1FCpm; Tue, 18 Jan 2022 20:42:58 +0800 (CST) Received: from [10.174.179.200] (10.174.179.200) by canpemm500006.china.huawei.com (7.192.105.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 18 Jan 2022 20:46:41 +0800 Subject: Re: [PATCH net] can: isotp: isotp_rcv_cf(): fix so->rx race problem To: Oliver Hartkopp , CC: , , , , References: <20220117120102.2395157-1-william.xuanziyang@huawei.com> <53279d6d-298c-5a85-4c16-887c95447825@hartkopp.net> From: "Ziyang Xuan (William)" Message-ID: <280e10c1-d1f4-f39e-fa90-debd56f1746d@huawei.com> Date: Tue, 18 Jan 2022 20:46:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <53279d6d-298c-5a85-4c16-887c95447825@hartkopp.net> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.200] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To canpemm500006.china.huawei.com (7.192.105.130) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Hi, > > the referenced syzbot issue has already been fixed in upstream here: > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=5f33a09e769a9da0482f20a6770a342842443776 > > ("can: isotp: convert struct tpcon::{idx,len} to unsigned int") > > Additionally this fix changes some behaviour that is required by the ISO 16765-2 specification (see below). > > On 17.01.22 13:01, Ziyang Xuan wrote: >> When receive a FF, the current code logic does not consider the real >> so->rx.state but set so->rx.state to ISOTP_IDLE directly. That will >> make so->rx accessed by multiple receiving processes concurrently. > > This is intentionally. "multiple receiving processes" are not allowed resp. specified by ISO 15765-2. Does it can be a network attack? It receives packets from network, but unexpected packets order make server panic. > >> The following syz problem is one of the scenarios. so->rx.len is >> changed by isotp_rcv_ff() during isotp_rcv_cf(), so->rx.len equals >> 0 before alloc_skb() and equals 4096 after alloc_skb(). That will >> trigger skb_over_panic() in skb_put(). >> >> ======================================================= >> CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc8-syzkaller #0 >> RIP: 0010:skb_panic+0x16c/0x16e net/core/skbuff.c:113 >> Call Trace: >>   >>   skb_over_panic net/core/skbuff.c:118 [inline] >>   skb_put.cold+0x24/0x24 net/core/skbuff.c:1990 >>   isotp_rcv_cf net/can/isotp.c:570 [inline] >>   isotp_rcv+0xa38/0x1e30 net/can/isotp.c:668 >>   deliver net/can/af_can.c:574 [inline] >>   can_rcv_filter+0x445/0x8d0 net/can/af_can.c:635 >>   can_receive+0x31d/0x580 net/can/af_can.c:665 >>   can_rcv+0x120/0x1c0 net/can/af_can.c:696 >>   __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5465 >>   __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5579 >> >> Check so->rx.state equals ISOTP_IDLE firstly in isotp_rcv_ff(). >> Make sure so->rx idle when receive another new packet. And set >> so->rx.state to ISOTP_IDLE after whole packet being received. >> >> Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") >> Reported-by: syzbot+4c63f36709a642f801c5@syzkaller.appspotmail.com >> Signed-off-by: Ziyang Xuan >> --- >>   net/can/isotp.c | 28 +++++++++++++++++----------- >>   1 file changed, 17 insertions(+), 11 deletions(-) >> >> diff --git a/net/can/isotp.c b/net/can/isotp.c >> index df6968b28bf4..a4b174f860f3 100644 >> --- a/net/can/isotp.c >> +++ b/net/can/isotp.c >> @@ -443,8 +443,10 @@ static int isotp_rcv_ff(struct sock *sk, struct canfd_frame *cf, int ae) >>       int off; >>       int ff_pci_sz; >>   +    if (so->rx.state != ISOTP_IDLE) >> +        return 0; >> + >>       hrtimer_cancel(&so->rxtimer); >> -    so->rx.state = ISOTP_IDLE; > > No matter in which receiving state we receive a first frame (FF) we are required to start a fresh reception process and/or terminate the current attempt. > > Best regards, > Oliver > >>         /* get the used sender LL_DL from the (first) CAN frame data length */ >>       so->rx.ll_dl = padlen(cf->len); >> @@ -518,8 +520,6 @@ static int isotp_rcv_cf(struct sock *sk, struct canfd_frame *cf, int ae, >>           so->lastrxcf_tstamp = skb->tstamp; >>       } >>   -    hrtimer_cancel(&so->rxtimer); >> - >>       /* CFs are never longer than the FF */ >>       if (cf->len > so->rx.ll_dl) >>           return 1; >> @@ -531,15 +531,15 @@ static int isotp_rcv_cf(struct sock *sk, struct canfd_frame *cf, int ae, >>               return 1; >>       } >>   +    hrtimer_cancel(&so->rxtimer); >> + >>       if ((cf->data[ae] & 0x0F) != so->rx.sn) { >>           /* wrong sn detected - report 'illegal byte sequence' */ >>           sk->sk_err = EILSEQ; >>           if (!sock_flag(sk, SOCK_DEAD)) >>               sk_error_report(sk); >>   -        /* reset rx state */ >> -        so->rx.state = ISOTP_IDLE; >> -        return 1; >> +        goto err_out; >>       } >>       so->rx.sn++; >>       so->rx.sn %= 16; >> @@ -551,21 +551,18 @@ static int isotp_rcv_cf(struct sock *sk, struct canfd_frame *cf, int ae, >>       } >>         if (so->rx.idx >= so->rx.len) { >> -        /* we are done */ >> -        so->rx.state = ISOTP_IDLE; >> - >>           if ((so->opt.flags & ISOTP_CHECK_PADDING) && >>               check_pad(so, cf, i + 1, so->opt.rxpad_content)) { >>               /* malformed PDU - report 'not a data message' */ >>               sk->sk_err = EBADMSG; >>               if (!sock_flag(sk, SOCK_DEAD)) >>                   sk_error_report(sk); >> -            return 1; >> +            goto err_out; >>           } >>             nskb = alloc_skb(so->rx.len, gfp_any()); >>           if (!nskb) >> -            return 1; >> +            goto err_out; >>             memcpy(skb_put(nskb, so->rx.len), so->rx.buf, >>                  so->rx.len); >> @@ -573,6 +570,10 @@ static int isotp_rcv_cf(struct sock *sk, struct canfd_frame *cf, int ae, >>           nskb->tstamp = skb->tstamp; >>           nskb->dev = skb->dev; >>           isotp_rcv_skb(nskb, sk); >> + >> +        /* we are done */ >> +        so->rx.state = ISOTP_IDLE; >> + >>           return 0; >>       } >>   @@ -591,6 +592,11 @@ static int isotp_rcv_cf(struct sock *sk, struct canfd_frame *cf, int ae, >>       /* we reached the specified blocksize so->rxfc.bs */ >>       isotp_send_fc(sk, ae, ISOTP_FC_CTS); >>       return 0; >> + >> +err_out: >> +    /* reset rx state */ >> +    so->rx.state = ISOTP_IDLE; >> +    return 1; >>   } >>     static void isotp_rcv(struct sk_buff *skb, void *data) > .