From: "Ziyang Xuan (William)" <william.xuanziyang@huawei.com>
To: Oliver Hartkopp <socketcan@hartkopp.net>, <mkl@pengutronix.de>
Cc: <davem@davemloft.net>, <kuba@kernel.org>,
<linux-can@vger.kernel.org>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net] can: isotp: isotp_rcv_cf(): fix so->rx race problem
Date: Thu, 20 Jan 2022 19:28:14 +0800 [thread overview]
Message-ID: <2aba02d4-0597-1d55-8b3e-2c67386f68cf@huawei.com> (raw)
In-Reply-To: <1fb4407a-1269-ec50-0ad5-074e49f91144@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 4309 bytes --]
>
> On 20.01.22 07:24, Ziyang Xuan (William) wrote:
>
>> I have reproduced the syz problem with Marc's commit, the commit can not fix the panic problem.
>> So I tried to find the root cause for panic and gave my solution.
>>
>> Marc's commit just fix the condition that packet size bigger than INT_MAX which trigger
>> tpcon::{idx,len} integer overflow, but the packet size is 4096 in the syz problem.
>>
>> so->rx.len is 0 after the following logic in isotp_rcv_ff():
>>
>> /* get the FF_DL */
>> so->rx.len = (cf->data[ae] & 0x0F) << 8;
>> so->rx.len += cf->data[ae + 1];
>>
>> so->rx.len is 4096 after the following logic in isotp_rcv_ff():
>>
>> /* FF_DL = 0 => get real length from next 4 bytes */
>> so->rx.len = cf->data[ae + 2] << 24;
>> so->rx.len += cf->data[ae + 3] << 16;
>> so->rx.len += cf->data[ae + 4] << 8;
>> so->rx.len += cf->data[ae + 5];
>>
>
> In these cases the values 0 could be the minimum value in so->rx.len - but e.g. the value 0 can not show up in isotp_rcv_cf() as this function requires so->rx.state to be ISOTP_WAIT_DATA.
Consider the scenario that isotp_rcv_cf() and isotp_rcv_cf() are concurrent for the same isotp_sock as following sequence:
isotp_rcv_cf()
if (so->rx.state != ISOTP_WAIT_DATA) [false]
isotp_rcv_ff()
so->rx.state = ISOTP_IDLE
/* get the FF_DL */ [so->rx.len == 0]
alloc_skb() [so->rx.len == 0]
/* FF_DL = 0 => get real length from next 4 bytes */ [so->rx.len == 4096]
skb_put(nskb, so->rx.len) [so->rx.len == 4096]
skb_over_panic()
>
> And when so->rx.len is 0 in isotp_rcv_ff() this check
>
> if (so->rx.len + ae + off + ff_pci_sz < so->rx.ll_dl)
> return 1;
>
> will return from isotp_rcv_ff() before ISOTP_WAIT_DATA is set at the end. So after that above check we are still in ISOTP_IDLE state.
>
> Or did I miss something here?
>
>> so->rx.len is 0 before alloc_skb() and is 4096 after alloc_skb() in isotp_rcv_cf(). The following
>> skb_put() will trigger panic.
>>
>> The following log is my reproducing log with Marc's commit and my debug modification in isotp_rcv_cf().
>>
>> [ 150.605776][ C6] isotp_rcv_cf: before alloc_skb so->rc.len: 0, after alloc_skb so->rx.len: 4096
>
>
> But so->rx_len is not a value that is modified by alloc_skb():
>
> nskb = alloc_skb(so->rx.len, gfp_any());
> if (!nskb)
> return 1;
>
> memcpy(skb_put(nskb, so->rx.len), so->rx.buf,
> so->rx.len);
>
>
> Can you send your debug modification changes please?
My reproducing debug as attachment and following:
diff --git a/net/can/isotp.c b/net/can/isotp.c
index df6968b28bf4..8b12d63b4d59 100644
--- a/net/can/isotp.c
+++ b/net/can/isotp.c
@@ -119,8 +119,8 @@ enum {
};
struct tpcon {
- int idx;
- int len;
+ unsigned int idx;
+ unsigned int len;
u32 state;
u8 bs;
u8 sn;
@@ -505,6 +505,7 @@ static int isotp_rcv_cf(struct sock *sk, struct canfd_frame *cf, int ae,
struct isotp_sock *so = isotp_sk(sk);
struct sk_buff *nskb;
int i;
+ bool unexpection = false;
if (so->rx.state != ISOTP_WAIT_DATA)
return 0;
@@ -562,11 +563,13 @@ static int isotp_rcv_cf(struct sock *sk, struct canfd_frame *cf, int ae,
sk_error_report(sk);
return 1;
}
-
+ if (so->rx.len == 0)
+ unexpection = true;
nskb = alloc_skb(so->rx.len, gfp_any());
if (!nskb)
return 1;
-
+ if (unexpection)
+ printk("%s: before alloc_skb so->rc.len: 0, after alloc_skb so->rx.len: %u\n", __func__, so->rx.len);
memcpy(skb_put(nskb, so->rx.len), so->rx.buf,
so->rx.len);
>
> Best regards,
> Oliver
>
>> [ 150.611477][ C6] skbuff: skb_over_panic: text:ffffffff881ff7be len:4096 put:4096 head:ffff88807f93a800 data:ffff88807f93a800 tail:0x1000 end:0xc0 dev:<NULL>
>> [ 150.615837][ C6] ------------[ cut here ]------------
>> [ 150.617238][ C6] kernel BUG at net/core/skbuff.c:113!
>>
>
> .
[-- Attachment #2: 0001-can-isotp-debug-for-reproducing-isotp_rcv-panic.patch --]
[-- Type: text/plain, Size: 1371 bytes --]
From 16c94e5aee258b1d856e29493746db9afce8963a Mon Sep 17 00:00:00 2001
From: Ziyang Xuan <william.xuanziyang@huawei.com>
Date: Thu, 20 Jan 2022 15:17:54 +0800
Subject: [PATCH] can: isotp: debug for reproducing isotp_rcv panic
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
---
net/can/isotp.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/can/isotp.c b/net/can/isotp.c
index df6968b28bf4..8b12d63b4d59 100644
--- a/net/can/isotp.c
+++ b/net/can/isotp.c
@@ -119,8 +119,8 @@ enum {
};
struct tpcon {
- int idx;
- int len;
+ unsigned int idx;
+ unsigned int len;
u32 state;
u8 bs;
u8 sn;
@@ -505,6 +505,7 @@ static int isotp_rcv_cf(struct sock *sk, struct canfd_frame *cf, int ae,
struct isotp_sock *so = isotp_sk(sk);
struct sk_buff *nskb;
int i;
+ bool unexpection = false;
if (so->rx.state != ISOTP_WAIT_DATA)
return 0;
@@ -562,11 +563,13 @@ static int isotp_rcv_cf(struct sock *sk, struct canfd_frame *cf, int ae,
sk_error_report(sk);
return 1;
}
-
+ if (so->rx.len == 0)
+ unexpection = true;
nskb = alloc_skb(so->rx.len, gfp_any());
if (!nskb)
return 1;
-
+ if (unexpection)
+ printk("%s: before alloc_skb so->rc.len: 0, after alloc_skb so->rx.len: %u\n", __func__, so->rx.len);
memcpy(skb_put(nskb, so->rx.len), so->rx.buf,
so->rx.len);
--
2.25.1
next prev parent reply other threads:[~2022-01-20 11:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-17 12:01 [PATCH net] can: isotp: isotp_rcv_cf(): fix so->rx race problem Ziyang Xuan
2022-01-18 7:58 ` Oliver Hartkopp
2022-01-18 12:46 ` Ziyang Xuan (William)
2022-01-18 14:44 ` Oliver Hartkopp
2022-01-20 6:24 ` Ziyang Xuan (William)
2022-01-20 8:23 ` Oliver Hartkopp
2022-01-20 11:28 ` Ziyang Xuan (William) [this message]
2022-01-20 14:46 ` Oliver Hartkopp
2022-01-21 1:50 ` Ziyang Xuan (William)
2022-01-27 19:44 ` Oliver Hartkopp
2022-01-28 7:56 ` Oliver Hartkopp
2022-01-28 8:07 ` Marc Kleine-Budde
2022-01-28 8:32 ` Oliver Hartkopp
2022-01-28 8:46 ` Marc Kleine-Budde
2022-01-28 14:48 ` Oliver Hartkopp
2022-02-07 8:11 ` Marc Kleine-Budde
2022-02-09 7:54 ` Oliver Hartkopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2aba02d4-0597-1d55-8b3e-2c67386f68cf@huawei.com \
--to=william.xuanziyang@huawei.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=socketcan@hartkopp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).