From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4A42C77B71 for ; Sat, 15 Apr 2023 02:19:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230150AbjDOCS5 (ORCPT ); Fri, 14 Apr 2023 22:18:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51638 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230058AbjDOCSz (ORCPT ); Fri, 14 Apr 2023 22:18:55 -0400 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 531AD2130; Fri, 14 Apr 2023 19:18:53 -0700 (PDT) Received: from kwepemi500015.china.huawei.com (unknown [172.30.72.55]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4PyxjY1pWjz17SjF; Sat, 15 Apr 2023 10:15:13 +0800 (CST) Received: from [10.174.178.171] (10.174.178.171) by kwepemi500015.china.huawei.com (7.221.188.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Sat, 15 Apr 2023 10:18:49 +0800 Subject: =?UTF-8?B?UmU6IOetlOWkjTogW1BBVENIIG5ldF0gbmV0OiBBZGQgY2hlY2sgZm9y?= =?UTF-8?Q?_csum=5fstart_in_skb=5fpartial=5fcsum=5fset=28=29?= To: Willem de Bruijn , Eric Dumazet CC: "davem@davemloft.net" , "kuba@kernel.org" , "pabeni@redhat.com" , "asml.silence@gmail.com" , "imagedong@tencent.com" , "brouer@redhat.com" , "keescook@chromium.org" , "jbenc@redhat.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <20230410022152.4049060-1-luwei32@huawei.com> <643447ba5224a_83e69294b6@willemb.c.googlers.com.notmuch> <450994d7-4a77-99df-6317-b535ea73e01d@huawei.com> <6436b5ba5c005_41e2294dd@willemb.c.googlers.com.notmuch> <643983f69b440_17854f2948c@willemb.c.googlers.com.notmuch> <64398b4c4585f_17abe429442@willemb.c.googlers.com.notmuch> From: "luwei (O)" Message-ID: <47fca2c7-db7c-0265-d724-38dffc62debe@huawei.com> Date: Sat, 15 Apr 2023 10:18:49 +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: <64398b4c4585f_17abe429442@willemb.c.googlers.com.notmuch> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.171] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemi500015.china.huawei.com (7.221.188.92) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2023/4/15 1:20 AM, Willem de Bruijn 写道: > Willem de Bruijn wrote: >> luwei (O) wrote: >>> yes, here is the vnet_hdr: >>> >>> flags: 3 >>> gso_type: 3 >>> hdr_len: 23 >>> gso_size: 58452 >>> csum_start: 5 >>> csum_offset: 16 >>> >>> and the packet: >>> >>> | vnet_hdr | mac header | network header | data ... | >>> >>> memcpy((void*)0x20000200, >>> "\x03\x03\x02\x00\x54\xe4\x05\x00\x10\x00\x80\x00\x00\x53\xcc\x9c\x2b" >>> "\x19\x3b\x00\x00\x00\x89\x4f\x08\x03\x83\x81\x04", >>> 29); >>> *(uint16_t*)0x200000c0 = 0x11; >>> *(uint16_t*)0x200000c2 = htobe16(0); >>> *(uint32_t*)0x200000c4 = r[3]; >>> *(uint16_t*)0x200000c8 = 1; >>> *(uint8_t*)0x200000ca = 0; >>> *(uint8_t*)0x200000cb = 6; >>> memset((void*)0x200000cc, 170, 5); >>> *(uint8_t*)0x200000d1 = 0; >>> memset((void*)0x200000d2, 0, 2); >>> syscall(__NR_sendto, r[1], 0x20000200ul, 0xe45ful, 0ul, 0x200000c0ul, 0x14ul); >> Thanks. So this can happen whenever a packet is injected into the tx >> path with a virtio_net_hdr. >> >> Even if we add bounds checking for the link layer header in pf_packet, >> it can still point to the network header. >> >> If packets are looped to the tx path, skb_pull is common if a packet >> traverses tunnel devices. But csum_start does not directly matter in >> the rx path (CHECKSUM_PARTIAL is just seen as CHECKSUM_UNNECESSARY). >> Until it is forwarded again to the tx path. >> >> So the question is which code calls skb_checksum_start_offset on the >> tx path. Clearly, skb_checksum_help. Also a lot of drivers. Which >> may cast the signed int return value to an unsigned. Even an u8 in >> the first driver I spotted (alx). >> >> skb_postpull_rcsum anticipates a negative return value, as do other >> core functions. So it clearly allowed in certain cases. We cannot >> just bound it. >> >> Summary after a long story: an initial investigation, but I don't have >> a good solution so far. Maybe others have a good suggestiong based on >> this added context. > Specific to skb_checksum_help, it appears that skb_checksum will > work with negative offset just fine.       In this case maybe not, since it checksums from within the mac header, and the mac header        will be stripped when the rx path checks the checksum. > > Perhaps the only issue is that the WARN_ON_ONCE compares signed to > unsigned, and thus incorrectly interprets a negative offset as > >= skb_headlen(skb) > . -- Best Regards, Lu Wei